Re: Another controversial question
Re: Another controversial question
- Subject: Re: Another controversial question
- From: Chris Kane <email@hidden>
- Date: Mon, 3 Sep 2001 22:16:41 -0700
On Sunday, September 2, 2001, at 01:33 PM, Drew McCormack wrote:
I hadn't realized that key-value coding would actually call the
accessor method if it were present.
Well, it still depends on which set of methods are being used. If the
"storedValue" variants are used, they fiddle with the ivars first, then
go for the accessor methods. EOF 3.0 (I think it was) added these for
performance reasons. That's also why the default values for
+useStoredAccessor and +accessInstanceVariablesDirectly, if you don't
implement them, favor poking the ivars. About these, the doc says:
This different search order allows an object to bypass processing
that is performed before returning a value through public API.
which comes back to your original concern. The docs describe these
public methods as "private API", for Foundation's and EOF's use, but
it's still possible for people to use these, since they are public.
Importantly, an accessor method can always be added later if the
implementation is to be changed, and the rest of the code will be
unaffected.
Provided that you know the class is being accessed with key-value
coding; in a larger or multi-person project you may not know until after
you've broken something.
Key-value coding bothers me some for the same reasons you had in your
original mail, but particularly annoys me (the way it's done) because:
1) to prevent ivar peeking and poking of your class, you need to know
that this thing over there called key-value coding exists and has
certain behaviors and the way to stop that is to put certain method
implementations in your class which otherwise adds no value;
2) nominally private methods (with "_" prefix) might be invoked by it
(or, an ivar touched), methods which aren't supposed to be
setters/getters, with possibly mysterious or detrimental effects; it's
quite common for a single conceptual bit of state to be spread across
multiple ivars, as one example -- to properly update an object multiple
of these little private accessors might be needed to be invoked. My
favorite example like this is this:
NSMutableArray *myArray;
...
[myArray takeValue:aNumber forKey:@"size"];
-- somebody was trying to set the size of a mutable array (to avoid
doubling at powers of two and go right to the soon-to-be-needed size).
There used to be a _size field on NSConcreteMutableArrays, so this could
set it! Of course, it didn't also reallocate the storage of the array,
so you can imagine what confusion resulted when the array thought the
storage was larger than it was. [Seems like it should have been obvious
this wasn't going to work...]
Of course, most developers wouldn't do something like this, right?
Chris Kane
Cocoa Frameworks, Apple