Hi. Le mar. 15 mars 2022 à 00:47, Matt Juntunen <matt.a.juntu...@gmail.com> a écrit : > > 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 had missed that subtlety; but it entails the question of what this functionality's intended usage is; e.g. would a user often need to access the "key" but not the associated "value"? Furthermore, what is actually meant here by "immutable instance" (since the "value" could be mutable without the map being aware of the fact)? > 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", Yes (I'm missing what is being resolved; it's just something being accessed). Best, Gilles > 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
