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.)”
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 (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
