Re: Convenience Methods
Re: Convenience Methods
- Subject: Re: Convenience Methods
- From: Erik Buck <email@hidden>
- Date: Wed, 26 Sep 2007 22:55:55 -0400
On Sep 26, 2007, at 10:51 PM, Jeff Laing wrote:
Erik stepped back on this, but I had this typed up so here goes:
On Sep 26, 2007, at 7:22 PM, Erik Buck wrote:
The following simple example illustrates the reality of writing an
algorithm that relies on a supposedly immutable object actually
being immutable.
Contrived example. :)
Not so much contrived as dependent on the mistaken belief that
[Deleted]
Yes. It was slightly contrived in order to make it as concise as
possible. This issue really manifests in much more complicated
situations when it would be nearly impossible to know that an
innocent message will have catastrophic mutating effects on a
seemingly unrelated object.
Consider the slightly less contrived example: You are looping through
a collection of widgets to determine if a particular object is
present. Aha! The object is there so you generate a notification
intending for the notification to result in a user interface update.
The observer of the notification responds by asking the widget
manager to re-sort the array before updating the user interface
because you wouldn't want to display an unsorted collection of
widgets. Um, Ooops! That supposedly immutable collection you were
looping through just mutated.
The only way to reliably avoid this unfortunate situation is to copy
the collection of widgets and loop through the copy.
_______________________________________________
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