On May 19, 2009, at 10:58 AM, Quincey Morris wrote:
On May 19, 2009, at 09:32, Jesper Storm Bache wrote:
I personally disagree with the Apple recommendation, and I vote for
calling [super dealloc] when initialization fails - because this
will invoke dealloc only in the base classes where init succeeded.
First of all, in general, it can't work. If it were permissible to
write '[super dealloc]' anywhere other than in a dealloc method, you'd
have to be certain that there were no outstanding extra retains on the
object, and you can't know that. One of the "base" inits might have
done something that resulted in a retain/autorelease on the object,
for example.
Interesting & a valid point.
Such a use case definitely does *not* work with an explicit dealloc
mechanism.
Second, in general, when an init method decides to fail, its object is
already partially initialized. So in addition to (hypothetically)
calling '[super dealloc]', it would also have to back out some
initializations, and it comes down to a choice between (a) adding code
to init to back out the initializations or (b) adding code to dealloc
to avoid doing anything dangerous on a partially-initialized object.
That is right. The issue I have with release is if you have a class
hierarchy of three classes A<-B<-C and B fails, then you will get a
dealloc call in C before C's init returned from [super init]. By
calling dealloc on the super class you get C++ style behavior, where
you only get destructor calls in instances where the init call
succeeded. It is correct that this require implementing init in a way
that provide proper clean up if a failure should occur.
The benefit we get from obj-c, is that we know that all ivars are set
to 0, so we do get some kind of class hierarchy wide initialization
before our initializers run.
If you use the [self release] method, then your canonical no-value
must be 0 for all of your data types.
I can't find any documentation stating that retain/autorelease in
initializers is bad, so following the Apple guide lines is the right
way to go.
In the obj-c world we then have to implement classes to be able to
handle a dealloc call before the initializer has completely executed.
Thanks for your comments.
Jesper
The problem with (a) is that it will duplicate -- multiple times if
there are multiple errors to detect -- some code that's already in
dealloc. The advantage of (b) is that it centralizes the knowledge of
how to handle un-initialization in dealloc. (In most cases, the only
backing out that needs to be done is releasing instance variables. As
far as that's concerned, [self dealloc] is safe without special-casing
anything.)
_______________________________________________
Cocoa-dev mailing list (Cocoa-dev@lists.apple.com)
Please do not post admin requests or moderator comments to the list.
Contact the moderators at cocoa-dev-admins(at)lists.apple.com
Help/Unsubscribe/Update your Subscription:
http://lists.apple.com/mailman/options/cocoa-dev/jsbache%40adobe.com
This email sent to jsba...@adobe.com
_______________________________________________
Cocoa-dev mailing list (Cocoa-dev@lists.apple.com)
Please do not post admin requests or moderator comments to the list.
Contact the moderators at cocoa-dev-admins(at)lists.apple.com
Help/Unsubscribe/Update your Subscription:
http://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com
This email sent to arch...@mail-archive.com
