• 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: Accessor methods and (auto)release: conclusion
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: Accessor methods and (auto)release: conclusion


  • Subject: Re: Accessor methods and (auto)release: conclusion
  • From: Marcel Weiher <email@hidden>
  • Date: Tue, 6 Aug 2002 19:36:48 +0200

On Tuesday, August 6, 2002, at 07:10 Uhr, Ondra Cada wrote:


On Tuesday, August 6, 2002, at 05:19 , Marcel Weiher wrote:

-(void)dealloc { ... [self setter:nil]; ... }

Don't do that. Why not? A subclass could very well override the setter to do something "non-simple", in which case you might be triggering serious computation. Just use [var release]; (beware of cycles, though).

Well... on the other hand, the computation might be needed! Just presume you use your own NSWindow extension, whose setTitle: adds the window's name into your own panel, functionally similar to the Window menu. Presumed NSWindow uses [self setTitle:nil], you are done, all works as it should. If not, you have to extend -dealloc as well to remove your title.

Once again, this is the special case, not the general case. Furthermore, what if setting the title stores something into your transaction log, sends an IPC message or whatever? This you definitely do not want happening in the *dealloc* method. Deallocs should not have side-effects, they should just remove the object in question.

This is the very reason I *do* use this pattern in my own classes: it allows me to extend their behaviour more easily and more dependably (since there's a less number of methods to be overridden for a desired result, and thus the probability I might forget some of them is smaller).

Suit yourself.

or, naturally, anything *functionally equivalent* -- in other words, fulfilling the agreement "the vended object would be valid (at least) in the entire scope of the autorelease pool (current in the moment the getter vas used)". Those plain accessors you advocate alas are not!

The ones I use and advocate do fulfill the conract of doing the simplest thing compatible with the retain/release rules.

Alas, it is not compatible with the somewhat more complicated Cocoa's retain/release/autorelese rules.

Yes it is.

Marcel

--
Marcel Weiher Metaobject Software Technologies
email@hidden www.metaobject.com
Metaprogramming for the Graphic Arts. HOM, IDEAs, MetaAd etc.
_______________________________________________
cocoa-dev mailing list | email@hidden
Help/Unsubscribe/Archives: http://www.lists.apple.com/mailman/listinfo/cocoa-dev
Do not post admin requests to the list. They will be ignored.

  • Follow-Ups:
    • Re: Accessor methods and (auto)release: conclusion
      • From: Ondra Cada <email@hidden>
References: 
 >Re: Accessor methods and (auto)release: conclusion (From: Ondra Cada <email@hidden>)

  • Prev by Date: Re: Accessor methods and (auto)release: conclusion
  • Next by Date: Re: Accessor methods and (auto)release: conclusion
  • Previous by thread: Re: Accessor methods and (auto)release: conclusion
  • Next by thread: Re: Accessor methods and (auto)release: conclusion
  • Index(es):
    • Date
    • Thread