Quincey, > On Aug 11, 2016, at 16:26, Quincey Morris > <quinceymor...@rivergatesoftware.com> wrote: > >> On Aug 11, 2016, at 12:50 , Sandor Szatmari <admin.szatmari....@gmail.com> >> wrote: >> >> I guess the answer is that the creation date property is not considered part >> of the 'meaning' of what the object is, and therefore would not be factored >> in when writing the -hash or -isEqual: methods. This is perfectly >> reasonable, as many objects have properties that do not contribute in >> answering the question, is this object functionally equivalent. > > After I posted, I realized I had merged two different questions. You had > first asked about examples of “this” in my original post: > >> The fact than an object is immutable does not (in general) mean that a copy >> can be represented by the same object reference. > > where I was talking only about references, and had nothing to say about > ‘hash’ or ‘isEqual:’. The creation date example was meant to show how a > different object reference might be needed for the copy. > > But the question of ‘hash’ and ‘isEqual:’ stability was also raised by you > and others. This gets very hard very quickly, because (AFAIK) there is little > explicit constraint on what is allowed. > > In particular, there is no absolute requirement about when an object’s ‘hash’ > value may change. That seems weird for immutable objects, but isn’t weird for > mutable objects. Indeed, the NSObjectProtocol documentation for ‘hash’ says > this: > >> "If a mutable object is added to a collection that uses hash values to >> determine the object’s position in the collection, the value returned by the >> hash method of the object must not change while the object is in the >> collection. Therefore, either the hash method must not rely on any of the >> object’s internal state information or you must make sure the object’s >> internal state information does not change while the object is in the >> collection. Thus, for example, a mutable dictionary can be put in a hash >> table but you must not change it while it is in there. (Note that it can be >> difficult to know whether or not a given object is in a collection.)”
I couldn't have immediately pointed to the documentation, but this was the concern I has lurking in the back of my head; objects' -hash and -ieEqual: changing while in a collection. Thanks for wrapping up the details so neatly! The question raised that I couldn't quite find the words for is something like, if your copying collections and a constituent object's -copy method is called in the process, which alters the 'functional equality' of the collections, then things would break when relying on functional equivalency of the collections or their constituent objects. I feel like this is answered now. This means to me: 1. If at all possible, and within reason, avoid mutable objects in collections (your swift points address this). 2. You really need to be overtly aware of these details when designing classes and implementing -hash and -isEqual: > > Strictly speaking, I see this as having two consequences: > > 1. There may be NSCopying mutable objects that are always unsuitable for hash > tables, simply because they can’t meet the above requirement (because, for > example, you can’t stop them from changing while in a collection, because > their hash is based on dynamic factors outside your control). > > 2. Since there is no *formal* distinction between mutable and immutable > objects, there is no formal constraint on either of: > > object.hash vs. object.copy.hash (== or not?) > [object isEqual: object.copy] (true or false?) > > Although I think hash/isEqual issues are separate from the original question, > it’s very useful to have the subject raised, because: > > a. It’s a great example of something that seems easy at a conceptual level, > but is very difficult in the details. > > b. It’s a great reason why Swift (and other similar languages) place such an > emphasis on value types (“structs”) as opposed to reference types > (“classes”), and why Swift implements collections as value types rather than > reference types. > > In a large number of cases, the Obj-C conventions about hash, isEqual: and > copy are really about simulating value types with reference types. This works > well as long as we stay away from the sharp edges. > I'm glad you made these points too! Thanks, Sandor _______________________________________________ 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: https://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com This email sent to arch...@mail-archive.com
