Re: [Foo new] vs [[Foo alloc] init]:
Re: [Foo new] vs [[Foo alloc] init]:
- Subject: Re: [Foo new] vs [[Foo alloc] init]:
- From: Gregory Weston <email@hidden>
- Date: Sun, 17 Feb 2008 08:25:34 -0500
On Feb 16, 2008, at 6:28 PM, Bill Bumgarner wrote:
If the behavior had changed to anything that avoided either of
those methods (keeping in mind that +alloc is a cover for
+allocWithZone: until the latter was effectively deprecated as
zones have fallen out of recommended practice), then there would
have been a binary compatibility issue.
You've repeated the assertion without actually explaining it. How
would it be a binary compatibility issue for new to either start or
stop directly invoking alloc or allocWithZone: rather than simply
performing comparable operations? If I can override +alloc to do
whatever I like as long as it performs a certain minimum required set
of actions, why would be be troublesome for +new to not directly
invoke +alloc as long as it performed that minimum required set of
actions?
Reading the docs, it explicitly states:
...
This method is a combination of alloc and init. Like alloc, it
initializes the isa instance variable of the new object so it
points to the class data structure. It then invokes the init
method to complete the initialization process.
...
From there, the documentation entirely discusses implementing
+new... as a cover for various -initWith... style initializers.
Thus, the bare behavior of +new is quite thoroughly well defined
as a combination of +alloc and -init (in the docs, the the two
method names are links to the documentation of said methods).
It's well defined as being functionally equivalent by default to
alloc and init. It is even defined, as I had already noted, as
invoking init specifically. Given that explicitness, I would argue
that it's likely meaningful that the documentation does *not*
explicitly indicate that it invokes alloc. In fact the implication
of "Like alloc, ..." is very strongly that it's only guaranteed to
be an equivalent, not a wrapper. And since any developer who wants
can override alloc and new at any time they like, even though
Apple *does* implement new to invoke alloc by default it cannot be
reliably said to do so.
The doc says "a combination of alloc and init" with the method
names hyperlinked to their actual documentation. I'm not sure how
that can be read to mean anything but that the methods are being
invoked.
I read it as indicating that it's a *functional* combination of those
two methods. I read the lack of explicit comment that it invokes
alloc as significant in context of the presence of the explicit
comment that it invokes init, bolstered by the indication that it
acts "like" alloc. The 10.4 documentation includes the precise
phasing you've excerpted and yet under 10.4.x new definitely does not
invoke alloc by default. I stand by my original comment in this
thread; the proposition ...
"[Foo new] is exactly equivalent to [[Foo alloc] init]"
... is false. It wasn't correct by default before 10.5 and it's not
reliable in any version of OS X. You can make it true by adding
additional conditions, and you can question the sanity of the
individual developer who makes it untrue for any of their classes (in
which case I'd likely join you), but the proposition is not true as
presented. Assuming it *is* true - that somehow new by definition
must invoke alloc - is an error and relying on that assumption can
get you into trouble. For example, if you support deployment on
Tiger, override +alloc in one of your classes and use +new to
instantiate that class, your override will not be used. That's all
I've been trying to say.
_______________________________________________
Cocoa-dev mailing list (email@hidden)
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:
This email sent to email@hidden