On Aug 11, 2016, at 17:16 , Steve Sisak <sgs-li...@codewell.com> wrote: > > This thread seems to have gone off into the weeds by way of tortured analogy. > ;-)
OK, spoil the fun! But … > This way if you want to add an object to a collection, calling -copy has the > effect of freezing the current value — the immutable class can optimize this > by just returning a new reference to the same object, but the caller doesn’t > have to know whether the object was immutable or a mutable subclass. I think the important point (which may be OT, but is still worth making) is there’s no formal definition of immutability in Obj-C. (There is in Swift.) There’s no clarification of what “values” means in the official NSCopying protocol description, so who knows which “values” have to be “identical” in the copy. If the object’s “values” are themselves class instances, there’s no clarification of what “identical” means, either. At risk of starting a different fire, or dying in different weeds, I’ll point out that *all* Obj-C objects (except for tagged pointers and compile time NSString literals) are strictly-speaking mutable, because they all have a public “retainCount” property that changes over time. By common consent, we agree to exempt certain things from disqualifying an object from immutability. The mutable retain count is one such thing. It is up to each class to decide what other things might also be exempt. _______________________________________________ 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
