On 19 Jan 2010, at 16:53, Shawn Rutledge wrote: > I'm accustomed to > things like Qt and Java where hashtables can contain anything for both > key and value.
This is not true (at least for Java and probably for QT for the same reason). From the API docs for the Map abstract class: "Note: great care must be exercised if mutable objects are used as map keys. The behavior of a map is not specified if the value of an object is changed in a manner that affects equals comparisons while the object is a key in the map. " From the docs for Object.hashCode() "Whenever it is invoked on the same object more than once during an execution of a Java application, the hashCode method must consistently return the same integer, provided no information used in equals comparisons on the object is modified." The Cocoa "restriction" on keys actually makes things a little easier. For instance, you can use NSMutableString as a key in an NSDictionary with no problems. However, if you try to use a StringBuffer or StringBuilder as a key in a Java map, you won't get the "natural" behaviour - two distinct StringBuffers with the same character sequence in them do not compare equal and if you override equals() in a subclass to make sure they do, you'd better not change a StringBuffer that happens to be a key in a map._______________________________________________ Cocoa-dev mailing list (Cocoa-dev@lists.apple.com) Please do not post admin requests or moderator comments to the list. Contact the moderators at cocoa-dev-admins(at)lists.apple.com Help/Unsubscribe/Update your Subscription: http://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com This email sent to arch...@mail-archive.com
