Re: accessor generation???
Re: accessor generation???
- Subject: Re: accessor generation???
- From: Lance Bland <email@hidden>
- Date: Fri, 5 Jul 2002 10:14:30 -0400
On Friday, July 5, 2002, at 08:23 AM, Phillip Mills wrote:
I've been doing OO stuff (non-Objective-C) for at least 10 years and my
experience is the same as yours. In fact, I'd come to believe that
simple accessors were a symptom of a possible bad design. They often
pointed to classes where no one had thought about their role or
behavior.
The Cocoa books and examples, however, give me an impression of a
different norm. Much of this stuff demonstrates limiting objects'
access to their own member variables and using things like...
[self setProp: 3];
...instead of...
prop = 3;
So I, probably along with others, was adapting my practice to what
seemed a Cocoa/Objective-C "cultural" thing. If we're being taught to
code everything using accessors rather than variable references, it
makes sense to automate the simple ones.
It's more than just cultural. Here are a few reasons:
- To make superclass ivars truly private.
- to reduce the "fragile base class" problem.
- so superclasses can have another level of indirection for their ivars,
like this:
void *_privateIvars;
_privateIvars = malloc(sizeof(__MyPrivateIvarStruct));
_privateIvars->window = window.
to eliminate the "fragile base class" problem. (memory alignment
guaranteed and no direct access of memory by subclassers).
- To fake out subclasses in thinking that they are using a simple
accessor method to get a ivar, when in fact they are using a more
general storage technique, such as looking up a key in a dictionary.
Then there were reasons for EOF and WO, but they are less documented.
There are also direct framework design criterion, but that is a
preference or specific design issue. I haven't been following this
thread very well, so I could be off base.
-lance
------------------------------------
Lance Bland
mailto:email@hidden
web charts at
http://www.vvi.com/products/chart
_______________________________________________
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.