Re: semantics of init
Re: semantics of init
- Subject: Re: semantics of init
- From: Marcel Weiher <email@hidden>
- Date: Wed, 4 Jun 2003 17:24:46 +0200
On Wednesday, June 4, 2003, at 03:16 Uhr, Wade Tregaskis wrote:
So I use my accessors to avoid direct instance variable access.
This protects me from self being nil without the test, and it even
protects me from a different type of object being returned. (If the
object being returned isn't compatible in the message-interface,
then it is just broken).
The problem that I see with using accessor methods in init is that it
could possibly create maintenance problems. Sending messages to
"self" before "self" is fully initialized could possibly create
situations where you, if you're not carefyl, try to access parts of
"self" that is not yet initialized. Do you see this as a problem, and
if so, how do you deal with that?
Another problem I'm seeing with this approach is performance - I don't
think ObjC messages can be inlined, by definition, so every [self xxx]
call is an extra expense you could probably do without. Plus, it may
muck up your object's initial message cache, by using a bunch of
setter methods that don't otherwise get used. So you'd see an extra
performance loss, initially.
In a word: no.
First, you are dealing with object creation here, and object creation
is about an order of magnitude more expensive (in the simplest cases)
than message sending. So the single message-send is utterly
insignificant. Potential cache interference is such a remote issue
that even worrying about at this points makes me wonder...
So if you are worried about accessor performance in initialization, you
should never use accessor anywhere, because just about every other
place would be much more sensitive to the relative cost of message
sending than object creation, except may disk and network I/O.
Anyway: this is an almost perfect example of a premature optimization
without the actual measurements to support the proposed optimization,
which would reveal it not to be one...
While I'm all for returning alternative instances and subclasses from
init methods, whenever the developer likes, I'm more hesitant in
supporting the returning of other classes entirely.
So would I, and using accessors in -init wasn't done with that in mind.
It just happens to handle that case as well, simply because it uses
*messaging*, which is what you should always do in a message-oriented
language unless there is a compelling reason not to.
[..]
With regards to the inevitable arguments that consistently using
setter functions makes it easier to manage changes to how you
represent and store your classes data,
It does, and is easier to code, and takes care of retain/release
automagically and is more robust.
my argument is that unless you're working on some super-massive class
with other people (in which case you've probably made a major design
mistake anyway), you should be able to manage any changes that may
occur with minimal extra effort.
Sure, but what's the benefit?
Marcel
--
Marcel Weiher Metaobject Software Technologies
email@hidden www.metaobject.com
Metaprogramming for the Graphic Arts. HOM, IDEAs, MetaAd etc.
f0249ab8b1af193ef5addcf39fdff5ca
_______________________________________________
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.