[concurrency-interest] Reference/IdentityMap toString
jason_mehrens at hotmail.com
Mon Aug 23 16:35:04 EDT 2010
[Tim wrote:] While bijectivity is an attractive property for a string representation function, it's not something anyone should depend on.
[Tim wrote:] I meant that because no one should be depending on toString being bijective, there's not much point in striving for bijectivity in toString implementations in the first place.
>From the callers point of view right? Otherwise, I'm (mis)interpreting the above as "bijectivity is attractive property but not worth doing".
The reason to do so is to walk like a Map (get/put) and talk like a Map (toString). ToString is dependent on the fact 'this' context is a map. The map implementation of a toString method is testable (which is one caller that depends on toString). If we throw all bijectivity out then there is no way to unit test a map implementation of toString (assuming it chooses to iterate over the contents). That would allow a map to legally iterate of the first element N times where N is the size and size is greater than one. Making the map look like it contains duplicate entries.
>So I don't think AbstractMap.toString() can be fairly described as "broken", even for identity maps.
Bringing it back my original question, you mean that because AbstractMap.toString is not required to be bijective it is free to not represent the equivalence relationship, therefore is not "broken". Correct?
>As others have mentioned, if you have a specific need to preserve a key's identity in a string representation -- e.g., debugging, logging -- there are several approaches one could use that don't involve complicating AbstractMap.toString.
The examples are great. They show that everyone is eager to solve a problem and help others. The core issue is what is the right thing for the map itself to do (callee not caller)? 100 more workarounds will not answer my original question.
I guess the practical version of my original question is: "Say some day the next great reference/identity map is being integrated into the java of the future. Should the implementation use AbstractMap.toString that suffers from some issues in this context or since it is a specialized map perhaps it should provide a specialized toString to fix these issues?"
-------------- next part --------------
An HTML attachment was scrubbed...
More information about the Concurrency-interest