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 more error prone, and less flexible. In particular, additional behavior should not be adorned to the accessor, and the accessor must never leak knowledge of the receiver to a third party during init or dealloc. Basically, these accessors must be very very boring. But if it's a synthesized accessor, wouldn't it be pretty much a given that that would be the case? That will be the case for your class, with its synthesized accessors. If a subclass overrides those accessors, though, you'll be invoking them during setup and teardown too. The overridden accessors, by definition, add side effects or behavior. - Jim ___ Cocoa-dev mailing list (Cocoa-dev@lists.apple.com) 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: http://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com This email sent to arch...@mail-archive.com
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 restrictions to the accessor that the superclass is not aware of. If you can't write your override of an accessor in such a way that you don't place additional restrictions on the superclass, you shouldn't do it. Because its not possible for you to make the assumption that the superclass will never care - without making (unjustifiable) assumptions about the superclasses implementation. My response was to someone presumably writing about Design Patterns, I believe who wanted to know what was the best approach to take. My opinion is that you should *not* assume that subclassers are idiots, because it doesn't matter how much bullet-proofing you put in, there's always going to be a worse idiot come along. Better to make them all have to work carefully, than to avoid using things *they* might screw up. I'll agree with Jeff on his points here. In my personal situation, I'm the only person working on code at my on- the-side home business. But, although I'm the only author, I have never had the need to subclass any accessors. And, I've always called accessors from within init and dealloc (as well as copyWithZone: and encodeWithCoder:). Such code is in shipping apps (Mac OS X and later iPhone OS) starting in 2004. The benefits of bottlenecking code through accessors like this is it can really help in debugging. I know for a fact that every access to a property does so via one line of code; easy to instrument and only one breakpoint needed. However, I also know that subclassing accessors may be needed. And in those cases, I'm going to assume that the coder(s) will understand the pitfalls. In my opinion, this is one of those all depends situations. ___ Ricky A. Sharp mailto:rsh...@instantinteractive.com Instant Interactive(tm) http://www.instantinteractive.com ___ Cocoa-dev mailing list (Cocoa-dev@lists.apple.com) 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: http://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com This email sent to arch...@mail-archive.com
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 when called in these methods. As Graham Chris note, -init and -dealloc are special. The problem is really larger than that, though. In Cocoa, most setters are called upon the receiver by another object as public API to change the receiver. The setters may have complex behaviors associated with them, either directly or via KVO. Change tracking, document dirtying, undo registration, recomputing derived values, etc. But the receiver may also wish to express the notion of a private change in state that does not do any of that. In this case, while an ivar may change state in a literal sense, the class is not changing state as defined by its public API. Perhaps the document remains clean, perhaps there is no undo, or perhaps derived values are left unchanged (typically because all the private state is being rolled back together, so recomputing them is pointless) You may need to distinguish between privately restoring state and publicly changing state Conflating the public accessors with setting an ivar during init or dealloc is troublesome and inflexible. As with privately restoring state, constructing state and destructing state are just not the same as publicly changing state. While it will work for many simple projects, as behavior is added to classes, it tends to scale poorly. Considering init dealloc blessed (or cursed) allows for maximum flexibility for accessors and subclasses while minimizing bizarre bugs due to objects being in a partially constructed state. It's not a law, but it is the most pragmatic rule of thumb. There are a great many kinds of bugs that can sprout from partially constructed objects. Subclasses may access uninitialized state, setters may register the object in a global table before init is finished creating a multi-threading bug, setters may allocate more memory during dealloc, etc 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, additional behavior should not be adorned to the accessor, and the accessor must never leak knowledge of the receiver to a third party during init or dealloc. Basically, these accessors must be very very boring. - Ben ___ Cocoa-dev mailing list (Cocoa-dev@lists.apple.com) 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: http://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com This email sent to arch...@mail-archive.com
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, additional behavior should not be adorned to the accessor, and the accessor must never leak knowledge of the receiver to a third party during init or dealloc. Basically, these accessors must be very very boring. But if it's a synthesized accessor, wouldn't it be pretty much a given that that would be the case? Charles ___ Cocoa-dev mailing list (Cocoa-dev@lists.apple.com) 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: http://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com This email sent to arch...@mail-archive.com
Re: Clarification on accessors? (was: Yet another memory management question)
On 08/07/2009 17:51, Caleb Strockbine ca...@mac.com 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 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? -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 when called in these methods. Cheers, Graham. -- Graham Lee Senior Mac Software Engineer tel: +44 1235 540266 SOPHOS - simply secure Sophos Plc, The Pentagon, Abingdon Science Park, Abingdon, OX14 3YP, United Kingdom. Company Reg No 2096520. VAT Reg No GB 348 3873 20. ___ Cocoa-dev mailing list (Cocoa-dev@lists.apple.com) 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: http://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com This email sent to arch...@mail-archive.com
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 the modern (64bit)
Objective-C runtime. Furthermore, you must use accessor for properties that
are not backed by instance variables e.g. properties stored in axillary
dictionaries etc. Accessor must be used in initializers and dealloc in at
least some cases. I like consistency, and I use accessors within initailizers
and dealloc. An excerpt of my current recommendation (especially a note:)
follows:
Confining Memory Management to Accessors
If the Accessors pattern is -[if supportFields]consistently applied, almost
all memory
management for objects can be confined to accessors. When initializing object
instances, use a set accessor to set the value of each object property. For
example, the following implementation of -(id)initWithStringValue:(NSString
*)aValue method uses an accessor to store the string value
rather than making a direct assignment to an instance variable:
-
(id)initWithStringValue:(NSString *)aValue
{
self = [super init];
[self setStringValue:aValue]; // set the
initial value of the property
return self;
}
The process of initializing instances
is described in Chapter 3, Two-Stage Creation.
The -dealloc method can indirectly release referenced objects
using the set accessors and avoid memory management code in its
implementation as
follows:
- (void)dealloc
{
[self setStringValue:nil]; // any previous string value is released
[super dealloc];
}
Note
Some programmers have historically avoided using accessors within
initializer methods and -dealloc
because a subclass may override inherited accessors to cause side effects.
Using the overridden accessors within the superclass’s initializer might invoke
side effects before the subclass instance is fully initialized. Similarly,
accessors called from within the
superclass’s -dealloc may cause side
effects in partially deallocated instances. However, there is no practical
alternative to using accessors when you use synthesized instance variables with
the modern Objective-C 2.0 runtime or use properties that are not implemented
as instance variables. In such cases,
accessors provide the only way to initialize the properties or set the
properties to nil.
___
Cocoa-dev mailing list (Cocoa-dev@lists.apple.com)
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:
http://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com
This email sent to arch...@mail-archive.com
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. -- Sean McBride, B. Eng s...@rogue-research.com Rogue Researchwww.rogue-research.com Mac Software Developer Montréal, Québec, Canada ___ Cocoa-dev mailing list (Cocoa-dev@lists.apple.com) 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: http://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com This email sent to arch...@mail-archive.com
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, not a feature. Correct. 'Tis a bug. A fixed one, too, if you have access to the Snow Leopard seeds or grab the clang compiler from the llvm.org repository. b.bum ___ Cocoa-dev mailing list (Cocoa-dev@lists.apple.com) 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: http://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com This email sent to arch...@mail-archive.com
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, what will get called? --Graham ___ Cocoa-dev mailing list (Cocoa-dev@lists.apple.com) 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: http://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com This email sent to arch...@mail-archive.com
Re: Clarification on accessors? (was: Yet another memory management question)
What about properties that aren't backed by instance variables? Accessors are still needed to set properties stored in an auxiliary dictionary etc. There are literally only hours left for me to change a recommendation in Cocoa Design Patterns that you SHOULD use accessors in initializers and -dealloc. Remind me again why I shouldn't ? --- On Wed, 7/8/09, Bill Bumgarner b...@mac.com wrote: From: Bill Bumgarner b...@mac.com Subject: Re: Clarification on accessors? (was: Yet another memory management question) To: Sean McBride s...@rogue-research.com Cc: Erik Buck erik.b...@sbcglobal.net, cocoa-dev@lists.apple.com Date: Wednesday, July 8, 2009, 7:23 PM 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, not a feature. Correct. 'Tis a bug. A fixed one, too, if you have access to the Snow Leopard seeds or grab the clang compiler from the llvm.org repository. b.bum ___ Cocoa-dev mailing list (Cocoa-dev@lists.apple.com) 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: http://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com This email sent to arch...@mail-archive.com
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 (e.g. The subclassed accessor may rely on state that's been torn down earlier in -dealloc). It's just not safe, unless you can guarantee that you own the entire inheritance chain. .chris On Jul 8, 2009, at 6:08 PM, Erik Buck erik.b...@sbcglobal.net wrote: What about properties that aren't backed by instance variables? Accessors are still needed to set properties stored in an auxiliary dictionary etc. There are literally only hours left for me to change a recommendation in Cocoa Design Patterns that you SHOULD use accessors in initializers and -dealloc. Remind me again why I shouldn't ? --- On Wed, 7/8/09, Bill Bumgarner b...@mac.com wrote: From: Bill Bumgarner b...@mac.com Subject: Re: Clarification on accessors? (was: Yet another memory management question) To: Sean McBride s...@rogue-research.com Cc: Erik Buck erik.b...@sbcglobal.net, cocoa-dev@lists.apple.com Date: Wednesday, July 8, 2009, 7:23 PM 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, not a feature. Correct. 'Tis a bug. A fixed one, too, if you have access to the Snow Leopard seeds or grab the clang compiler from the llvm.org repository. b.bum ___ Cocoa-dev mailing list (Cocoa-dev@lists.apple.com) 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: http://lists.apple.com/mailman/options/cocoa-dev/ctp%40apple.com This email sent to c...@apple.com ___ Cocoa-dev mailing list (Cocoa-dev@lists.apple.com) 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: http://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com This email sent to arch...@mail-archive.com
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 override an accessor has had its dealloc method called already, so it should know to have put back anything that matters. Now, if you want to design based on the assumption that everyone else will do a crappy job, that's a different story. It's just not safe, unless you can guarantee that you own the entire inheritance chain. Someone more knowledgeable than me should bring up the discussion about using the need to use the 'view' set-accessor in dealloc of subclassed view controllers, I think it was. ___ Cocoa-dev mailing list (Cocoa-dev@lists.apple.com) 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: http://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com This email sent to arch...@mail-archive.com
Re: Clarification on accessors? (was: Yet another memory management question)
On Wed, Jul 8, 2009 at 7:28 PM, Jeff Laingjeff.la...@spatialinfo.com 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 your -dealloc method required your accessors to not rely on certain state. (e.g. The subclassed accessor may rely on state that's been torn down earlier in -dealloc). But any subclass that's going to override an accessor has had its dealloc method called already, so it should know to have put back anything that matters. Now, if you want to design based on the assumption that everyone else will do a crappy job, that's a different story. So you're essentially saying everyone's derived accessors must check if -dealloc has been called and avoid doing anything that might interfere with super's implementation of -dealloc. That doesn't seem tenable. It's just not safe, unless you can guarantee that you own the entire inheritance chain. Someone more knowledgeable than me should bring up the discussion about using the need to use the 'view' set-accessor in dealloc of subclassed view controllers, I think it was. Don't see what the issue is here. As long as -[NSViewController dealloc] doesn't rely on -view -- and it's this independence that we're discussing here -- then you can use it just fine (as long as you do it before calling super's implementation of -dealloc, otherwise all bets are off). --Kyle Sluder ___ Cocoa-dev mailing list (Cocoa-dev@lists.apple.com) 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: http://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com This email sent to arch...@mail-archive.com
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 aware of. If you can't write your override of an accessor in such a way that you don't place additional restrictions on the superclass, you shouldn't do it. Because its not possible for you to make the assumption that the superclass will never care - without making (unjustifiable) assumptions about the superclasses implementation. My response was to someone presumably writing about Design Patterns, I believe who wanted to know what was the best approach to take. My opinion is that you should *not* assume that subclassers are idiots, because it doesn't matter how much bullet-proofing you put in, there's always going to be a worse idiot come along. Better to make them all have to work carefully, than to avoid using things *they* might screw up. So you're essentially saying everyone's derived accessors must check if -dealloc has been called and avoid doing anything that might interfere with super's implementation of -dealloc. That doesn't seem tenable. Not everyones - only the ones that know they depend on some complicated local state that they might have screwed up. You can assume that the superclasses state is just fine because he hasn't been dealloc'd yet. Someone more knowledgeable than me should bring up the discussion about using the need to use the 'view' set-accessor in dealloc of subclassed view controllers, I think it was. Don't see what the issue is here. As long as -[NSViewController dealloc] doesn't rely on -view -- and it's this independence that we're discussing here -- then you can use it just fine (as long as you do it before calling super's implementation of -dealloc, otherwise all bets are off). As I said, someone more knowledgeable than I needs to respond but as I recall, the issue went that the view controller superclass implemented some sort of additional cleanup that only occurred if you used the accessor to set view to nil. If you just set the instance variable to nil, it would leak. ___ Cocoa-dev mailing list (Cocoa-dev@lists.apple.com) 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: http://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com This email sent to arch...@mail-archive.com
