Re: Clarification on accessors? (was: Yet another memory management question)

On Jul 9, 2009, at 5:52 PM, Charles Srstka wrote: On Jul 9, 2009, at 4:29 PM, Ben Trumbull wrote: It may be that under certain circumstances (dictionary storage, synthesized properties on 10.5, etc) that you must use an accessor method even in init & dealloc. That requires more care, is mor

Re: Clarification on accessors? (was: Yet another memory management question)

On Jul 9, 2009, at 4:29 PM, Ben Trumbull wrote: It may be that under certain circumstances (dictionary storage, synthesized properties on 10.5, etc) that you must use an accessor method even in init & dealloc. That requires more care, is more error prone, and less flexible. In particular,

Re: Clarification on accessors? (was: Yet another memory management question)

-init and -dealloc are special in that the object is not in a consistent state during those methods (it either hasn't yet entered it's "initial" state or is transitioning out of its "final" state). If your accessors rely on the internal state of the object being "normal", they could blow up

Re: Clarification on accessors? (was: Yet another memory management question)

On Jul 8, 2009, at 10:16 PM, Jeff Laing wrote: No, it doesn't. It would in fact violate the encapsulation principle if your -dealloc method required your accessors to not rely on certain state. The "ability to override accessors violates encapsulation" because it adds additional restric

RE: Clarification on accessors? (was: Yet another memory management question)

> No, it doesn't. It would in fact violate the encapsulation principle > if your -dealloc method required your accessors to not rely on certain > state. The "ability to override accessors violates encapsulation" because it adds additional restrictions to the accessor that the superclass is not a

Re: Clarification on accessors? (was: Yet another memory management question)

On Wed, Jul 8, 2009 at 7:28 PM, Jeff Laing wrote: >> Because you have no idea what subclassers may do in their overrides of >> the accessors > > Sort of invalidates the whole encapsulation promise of OO design, doesn't it? No, it doesn't. It would in fact violate the encapsulation principle if yo

RE: Clarification on accessors? (was: Yet another memory management question)

> Because you have no idea what subclassers may do in their overrides of > the accessors Sort of invalidates the whole encapsulation promise of OO design, doesn't it? > (e.g. The subclassed accessor may rely on state that's > been torn down earlier in -dealloc). But any subclass that's going to

Re: Clarification on accessors? (was: Yet another memory management question)

n Patterns" that you SHOULD use accessors in initializers and -dealloc. Remind me again why I shouldn't ? --- On Wed, 7/8/09, Bill Bumgarner wrote: From: Bill Bumgarner Subject: Re: Clarification on accessors? (was: Yet another memory management question) To: "Sean Mc

Re: Clarification on accessors? (was: Yet another memory management question)

in initializers and -dealloc.  Remind me again why I shouldn't ? --- On Wed, 7/8/09, Bill Bumgarner wrote: From: Bill Bumgarner Subject: Re: Clarification on accessors? (was: Yet another memory management question) To: "Sean McBride" Cc: "Erik Buck" , cocoa-dev@lists.ap

Re: Clarification on accessors? (was: Yet another memory management question)

On 09/07/2009, at 2:51 AM, Caleb Strockbine wrote: Really? Are -init and -dealloc special in some way that makes it a bad idea to use accessors? If you've got an accessor for myArray, why wouldn't you just say: self.myArray = nil? They are special. If a subclass overrides the accessor,

Re: Clarification on accessors? (was: Yet another memory management question)

On Jul 8, 2009, at 1:40 PM, Sean McBride wrote: On 7/8/09 11:20 AM, Erik Buck said: The bottom line is that accessors are the only way to set synthesized instance variables to nil in the modern (64bit) Objective-C runtime. True. But if I remember previous discussions correctly, that's a bug, no

Re: Clarification on accessors? (was: Yet another memory management question)

On 7/8/09 11:20 AM, Erik Buck said: >The bottom line is that accessors are the only way to set synthesized >instance variables to nil in the modern (64bit) Objective-C runtime. True. But if I remember previous discussions correctly, that's a bug, not a feature. -- __

Re: Clarification on accessors? (was: Yet another memory management question)

I have re-written the Accessors chapter of "Cocoa Design Patterns" several times because of controversy over whether accessors should, can, must or must not be used in initializers and dealloc.  The bottom line is that accessors are the only way to set synthesized instance variables to nil in th

Re: Clarification on accessors? (was: Yet another memory management question)

On 08/07/2009 17:51, "Caleb Strockbine" wrote: > > On Jul 4, 2009, at 9:37 PM, mmalc wrote: > >> In an initaliser method and in dealloc, you should typically set or >> release the variable directly, so in dealloc it would be >> [myArray release]; > > Really? Are -init and -dealloc special in

Clarification on accessors? (was: Yet another memory management question)

On Jul 4, 2009, at 9:10 PM, mmalc wrote: If you manipulate an instance variable anywhere other than in an initialiser or a dealloc method, you should use a suitable accessor method. On Jul 5, 2009, at 6:53 AM, mmalc wrote: On Jul 4, 2009, at 9:40 PM, WT wrote: [...] There is plenty of Ap

Re: Yet another memory management question

On Jul 5, 2009, at 8:23 AM, Michael Ash wrote: It's the same benefit as anywhere else. You have two places, viewDidUnload and dealloc, which perform the exact same action. They do not perform the "exact same action". In dealloc, you obviously relinquish ownership of all objects you own (and

Re: Yet another memory management question

On Sun, Jul 5, 2009 at 12:10 AM, mmalc Crawford wrote: >> Both are fine, but I would suggest something like the following, just >> because it avoids code duplication: >> - (void)viewDidUnload >> { >>   [self dispose]; >> } >> > > It is not clear here what is the benefit of "avoiding code duplicatio

Re: Yet another memory management question

On Sun, Jul 5, 2009 at 7:01 AM, DKJ wrote: > Have I finally got it right? Your dealloc method must include [super dealloc]; at the end of it. -Shawn ___ Cocoa-dev mailing list (Cocoa-dev@lists.apple.com) Please do not post admin requests or moderator

Re: Yet another memory management question

On 4-Jul-09, at 21:53 , mmalc Crawford wrote: Use of accessor methods is described plainly here: If I understand this example correctly, I could do the same thin

Re: Yet another memory management question

On Jul 5, 2009, at 4:02 AM, Benjamin Dobson wrote: On 5 Jul 2009, at 05:10:12, mmalc Crawford wrote: If you manipulate an instance variable anywhere other than in an initialiser or a dealloc method, you should use a suitable accessor method. Does this apply to instance variables that ar

Re: Yet another memory management question

On 5 Jul 2009, at 05:10:12, mmalc Crawford wrote: If you manipulate an instance variable anywhere other than in an initialiser or a dealloc method, you should use a suitable accessor method. Does this apply to instance variables that are not objects too? ___

Re: Yet another memory management question

On Jul 5, 2009, at 6:53 AM, mmalc Crawford wrote: Indeed. That's the problem with copy/paste and doing things in Mail, rather than from real code, ie, sometimes we all make silly mistakes. Not an earth-shattering mistake to make in this list, though, since you get a warning when trying to c

Re: Yet another memory management question

On Jul 4, 2009, at 9:40 PM, WT wrote: In general, this is not recommended. If you manipulate an instance variable anywhere other than in an initialiser or a dealloc method, you should use a suitable accessor method. - (void)viewDidLoad { id anObject = [[NSObject alloc] init]; [self set

Re: Yet another memory management question

On Jul 5, 2009, at 6:10 AM, mmalc Crawford wrote: On Jul 4, 2009, at 8:11 PM, WT wrote: The following is ok, though, assuming that you have appropriately declared myObject in your class (for example, as an instance variable): - (void)viewDidLoad { myObject = [[NSObject alloc] init]; }

Re: Yet another memory management question

On Jul 4, 2009, at 9:31 PM, DKJ wrote: On 4-Jul-09, at 21:10 , mmalc Crawford wrote: you should use accessor methods rather than direct variable manipulation Would declaring all the variables as properties, and then synthesising them, take care of this? Strictly, this is an orthogonal is

Re: Yet another memory management question

On 4-Jul-09, at 21:10 , mmalc Crawford wrote: you should use accessor methods rather than direct variable manipulation Would declaring all the variables as properties, and then synthesising them, take care of this? If so, what should I do in dealloc for those variables? For example, suppo

Re: Yet another memory management question

On Jul 4, 2009, at 8:11 PM, WT wrote: The following is ok, though, assuming that you have appropriately declared myObject in your class (for example, as an instance variable): - (void)viewDidLoad { myObject = [[NSObject alloc] init]; } In general, this is not recommended. If you manipu

Re: Yet another memory management question

On Jul 5, 2009, at 5:34 AM, DKJ wrote: In fact I'm now going through my code line-by-line, checking all the alloc, retain, copy etc. statements. While doing so I've come across another thing that puzzles me. Xcode very kindly provides template code when I create new files for classes like

Re: Yet another memory management question

In fact I'm now going through my code line-by-line, checking all the alloc, retain, copy etc. statements. While doing so I've come across another thing that puzzles me. Xcode very kindly provides template code when I create new files for classes like UIViewController. (But this is still a C

Re: Yet another memory management question

On Jul 5, 2009, at 4:39 AM, DKJ wrote: Is this the right way to do it? Not quite... - (void)viewDidLoad { id myObject = [[NSObject alloc] init]; } Your myObject is a local variable, so it will go out of scope when viewDidLoad returns. That means you won't be able to refer to the obj

Yet another memory management question

Is this the right way to do it? - (void)viewDidLoad { id myObject = [[NSObject alloc] init]; } - (void)viewDidUnload { [myObject release]; myObject = nil; } - (void)dealloc { [myObject release]; } ___ Cocoa-dev mailing list (Cocoa-dev@lis