• 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: Properties and memory management – sorry, not send to the list
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: Properties and memory management – sorry, not send to the list


  • Subject: Re: Properties and memory management – sorry, not send to the list
  • From: Negm-Awad Amin <email@hidden>
  • Date: Tue, 5 Aug 2008 13:08:26 +0200


Am Di,05.08.2008 um 11:57 schrieb Uli Kusterer:

You may fire off observer methods too, which is probably undesirable.

Lucky then, that I adopted GNUstep-style ASSIGN() and DESTROY() macros for these purposes, and since most of my code still needs to be 10.4-compatible, I've mostly been using those:


	<http://www.zathras.de/angelweb/sourcecode.htm#UKHelperMacros>

Though I vaguely remember getting lectured by someone about why it's better to *always* use the accessors a while ago ... wish I remembered what the reasoning behind that was, and why I thought it might be a good idea to follow that, but OTOH didn't follow it :-/

The advantages are:
- You have only one place per property, which handles the memory management. Just imagine, that you change the type of reference from hard to weak. You have to handle that change only inside the setter.
- You have side-effects you want to use at deallocation time, too: the property refers to something "outside", which has to be deallocated, turn of, … manually. Think of a guard wiith property that adds observations to another object. Changing the proprety (the referred object) in any case (including the case of deallocation) should delete the observation. So the settter is a single place, where you can handle it.


disadvantages:
- side-effects at dellocation time, which you do not want to use: I mentioned undo registration.


But I think, that the problem figured out by Ken (being observed in - dealloc), does not exist . Observations has to be removed by every object which sends a retain to an instance Before the deallocation takes place (-dealloc is called after a -retain) the obseving object already had to be removed. If there is still an observation of an object running through -dealloc, you have another problem. No observed object should disappear.

My 0,05 $

Amin



Cheers,
-- Uli Kusterer
"The Witnesses of TeachText are everywhere..."
http://www.zathras.de
_______________________________________________

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: 
 >Properties and memory management (From: Mike Manzano <email@hidden>)
 >Re: Properties and memory management (From: Jonathan Hess <email@hidden>)
 >Re: Properties and memory management (From: Uli Kusterer <email@hidden>)
 >Re: Properties and memory management (From: "Ken Ferry" <email@hidden>)
 >Re: Properties and memory management (From: Negm-Awad Amin <email@hidden>)
 >Re: Properties and memory management (From: Uli Kusterer <email@hidden>)

  • Prev by Date: Re: Localize App Title?
  • Next by Date: Re: Localize App Title?
  • Previous by thread: Re: Properties and memory management
  • Next by thread: Re: Properties and memory management
  • Index(es):
    • Date
    • Thread