Hello, > Do I understand correctly that the "resolveEntry" method which you added behaves as my above "getEntry"?
Correct. > If so, the latter can replace both "resolve" methods, for a (c)leaner API. That would work. I would need to add a matching "get" method to PointSet to provide the same functionality there. One consideration here is that the "resolveEntry" method creates and returns an immutable Entry instance with each call. The "resolveKey" method avoids this. I'm not sure if this will have an impact on performance. I'll try reducing the API as you suggest and include it in the PR if it doesn't make a difference in performance. Do you prefer the "get" verb over "resolve", e.g. "getEntry" vs "resolveEntry"? Regards, Matt On Mon, Mar 14, 2022 at 2:19 PM Gilles Sadowski <gillese...@gmail.com> wrote: > > Hello. > > Le lun. 14 mars 2022 à 16:19, Matt Juntunen > <matt.a.juntu...@gmail.com> a écrit : > > > > Gilles, > > > > > it would be great to keep the tutorials/userguide in sync. > > > > Sounds good. I'll update the user guide in this PR. > > > > > I'm a little bit confused: Isn't it always the case that > > getEntry(p).getKey() > > will return the originally inserted (i.e. "canonical") point (i.e. not "p")? > > > > Map does not contain a "getEntry" method. If it did, that would indeed > > be preferable. > > Do I understand correctly that the "resolveEntry" method which > you added behaves as my above "getEntry"? If so, the latter can > replace both "resolve" methods, for a (c)leaner API. > > > > Unless I'm missing a standard use-case, the specialized methods > > "closestFirst" and "farthestFirst" don't seem useful (and wasteful > > of computing resources: If iterating over the whole set, why would > > one want to start from some particular point?). > > > > Could you post this comment on the JIRA issue and we can continue the > > discussion there? > > Done. > > Regards, > Gilles > > --------------------------------------------------------------------- > To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org > For additional commands, e-mail: dev-h...@commons.apache.org > --------------------------------------------------------------------- To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org For additional commands, e-mail: dev-h...@commons.apache.org