Re: semantics of init
Re: semantics of init
- Subject: Re: semantics of init
- From: Wade Tregaskis <email@hidden>
- Date: Wed, 4 Jun 2003 23:16:56 +1000
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.
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. I would imagine
your init method should, in that case, return only 'id', and thus the
end users would have to deal with casting and so forth explicitly.
Plus, methods which do such things should have it well documented, in
addition to being fairly intuitive anyway - i.e. no one questions that
the common 'delegate' method could return anything - init should be no
different, in documented cases.
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, 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.
Wade Tregaskis
-- Sed quis custodiet ipsos custodes?
_______________________________________________
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.