• Open Menu Close Menu
  • Apple
  • Shopping Bag
  • Apple
  • Mac
  • iPad
  • iPhone
  • Watch
  • TV
  • Music
  • Support
  • Search apple.com
  • Shopping Bag

Lists

Open Menu Close Menu
  • Terms and Conditions
  • Lists hosted on this site
  • Email the Postmaster
  • Tips for posting to public mailing lists
Re: Mutating message sent to immutable object
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: Mutating message sent to immutable object


  • Subject: Re: Mutating message sent to immutable object
  • From: Ken Thomases <email@hidden>
  • Date: Sun, 01 Sep 2013 23:13:56 -0500

On Sep 1, 2013, at 6:36 PM, Kyle Sluder wrote:

> On Sep 1, 2013, at 1:41 PM, Greg Parker <email@hidden> wrote:
>
>> You're not entirely left up to their whim. A return value whose declared type is immutable imposes restrictions on both sides:
>> 1. You must not mutate the returned object.
>> 2. The returned object will not be mutated behind your back by anyone else.
>
> Sadly, the frameworks don't always live up to their end of the bargain on this one.
>
> Sometimes their failure to do so is documented—see -[NSTextStorage string], for instance. But usually it’s not.

The docs I linked to earlier strongly imply that there's no such restriction on the side which vends a mutable object through an immutable-typed reference.
https://developer.apple.com/library/ios/documentation/general/conceptual/CocoaEncyclopedia/ObjectMutability/ObjectMutability.html#//apple_ref/doc/uid/TP40010810-CH5-SW65

It says things like:

> • If you have a mutable collection that is frequently changed and that you frequently hand out to clients (that is, you return it directly in a getter accessor method), you run the risk of mutating something that your clients might have a reference to. If this risk is probable, the instance variable should be immutable.

That last sentence suggests the "restriction" is a good idea but not absolute.

The example given using -[NSView subviews] makes little sense if the restriction were really a restriction:

> • You ask NSView for its subviews (with the subviews method) and it returns an object that is declared to be an NSArray but which could be an NSMutableArray internally. Then you pass that array to some other code that, through introspection, determines it to be mutable and changes it. By changing this array, the code is mutating internal data structures of the NSView class.

It's ostensibly about the caller mutating the internal data structure of NSView, but its implication is that the caller has a reference to NSView's internal data structure that NSView itself might modify at any time.

And most damning is the whole subsection titled "Make Snapshots of Received Objects" which outright states that objects received as immutable may change out from under you and puts the onus on you to deal with that:

> If you want to ensure that a supposedly immutable object received from a method does not mutate without your knowing about it, you can make snapshots of the object by copying it locally.

Regards,
Ken


_______________________________________________

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


References: 
 >Re: Mutating message sent to immutable object (From: Greg Parker <email@hidden>)
 >Re: Mutating message sent to immutable object (From: Kyle Sluder <email@hidden>)

  • Prev by Date: Re: Mutating message sent to immutable object
  • Next by Date: Re: performKeyEquivalent called twice for some key strokes
  • Previous by thread: Re: Mutating message sent to immutable object
  • Next by thread: Re: performKeyEquivalent called twice for some key strokes
  • Index(es):
    • Date
    • Thread