• 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: Don't make me override -(void)release
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: Don't make me override -(void)release


  • Subject: Re: Don't make me override -(void)release
  • From: glenn andreas <email@hidden>
  • Date: Thu, 27 Dec 2007 16:23:11 -0600


On Dec 27, 2007, at 3:58 PM, Charles Steinman wrote:


--- glenn andreas <email@hidden> wrote:

So what's a good way to unbind objects that don't
have clean cut
release patterns (since this will only be released
when the last
reference is removed, and there's no obvious case of
knowing,
especially since it may be in the dictionary more
than once under
different keys, as well as the array that keeps the
order, and if
something is "hidden" is is removed from that
array)?

It seems to me that -removeAllItems would be the best place for the view to remove itself as an observer (because that is when the view no longer cares about the object's changes).


The place where the view's [myCollection removeAllItems] is called would be just one of many possible places that the item could be released (since there are a bunch of routines to change/remove objects in the collection by name, as well as other sorts of manipulations).

Basically, it seems error prone to have to have a parallel set of code to track if the item is valid or not - if it's referenced (by something from somewhere), it's there, if not, it's not (and will be released). NSDictionary already tracks everything for it, and when the reference count drops to zero and the object is released (because it's not referenced in the dictionary any more) it goes away. Adding a bunch of code to everything that modifies this dictionary to see if the result will be that the item is removed (and if so, call the item's "removeView" method) seems error prone and awkward.

Ultimately, I'm thinking it's an error in the KVO "warning" message system, which shouldn't kick in until the object is actually freed (i.e., when NSObject's dealloc calls NSDeallocateObject), as opposed to before the first line of derived dealloc routine (which prevents the object from being able to unbind anything it owns).


Glenn Andreas email@hidden
<http://www.gandreas.com/> wicked fun!
quadrium | prime : build, mutate, evolve, animate : the next generation of fractal art




_______________________________________________

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: Don't make me override -(void)release (From: Charles Steinman <email@hidden>)

  • Prev by Date: Re: Don't make me override -(void)release
  • Next by Date: "deviceTypeForPath:"
  • Previous by thread: Re: Don't make me override -(void)release
  • Next by thread: "deviceTypeForPath:"
  • Index(es):
    • Date
    • Thread