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
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
-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
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,
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
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
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
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.
--
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,
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,
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
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
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
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
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
15 matches
Mail list logo
