Hello, I've made the following changes to the PR: - removed the "resolveKey" method from PointMap - renamed PointMap.resolveEntry to PointMap.getEntry and PointSet.resolve to PointSet.get - added an entry on PointMap/PointSet to the user guide - addressed Github comments (thanks, Bruno!)
I ran some performance tests regarding the immutable entry instance created in the PointMap.getEntry method and there seems to be no impact. > Furthermore, what is actually meant here by "immutable instance" (since the "value" could be mutable without the map being aware of the fact)? It is immutable in that the object reference used as the entry value cannot be changed. This reference could point to a mutable object. This is the same behavior as other Map implementations. Regards, Matt On Tue, Mar 15, 2022 at 10:51 AM Gilles Sadowski <gillese...@gmail.com> wrote: > > 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 > --------------------------------------------------------------------- To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org For additional commands, e-mail: dev-h...@commons.apache.org
