Re: Objective-C basics - (Why NSNumber conforms to NSCopying protocol)
Re: Objective-C basics - (Why NSNumber conforms to NSCopying protocol)
- Subject: Re: Objective-C basics - (Why NSNumber conforms to NSCopying protocol)
- From: Quincey Morris <email@hidden>
- Date: Thu, 11 Aug 2016 13:26:38 -0700
- Feedback-id: 167118m:167118agrif8a:167118szerIvDxml:SMTPCORP
On Aug 11, 2016, at 12:50 , Sandor Szatmari <email@hidden> 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.)”
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.
_______________________________________________
Cocoa-dev mailing list (email@hidden)
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:
This email sent to email@hidden