Re: [Foo new] vs [[Foo alloc] init]:
Re: [Foo new] vs [[Foo alloc] init]:
- Subject: Re: [Foo new] vs [[Foo alloc] init]:
- From: Bill Bumgarner <email@hidden>
- Date: Sat, 16 Feb 2008 15:28:08 -0800
On Feb 16, 2008, at 1:16 PM, Gregory Weston wrote:
On Feb 16, 2008, at 12:11 PM, Bill Bumgarner wrote:
On Feb 16, 2008, at 4:56 AM, Gregory Weston wrote:
Without that guarantee, there's a different between saying "this
statement accurately describes all current implementations" and
"this statement is correct." It is not correct in general to say
that "[Foo new] is exactly equivalent to [[Foo alloc] init]."
Those are the kind of assumptions that burn you after you've
forgotten you made them in the first place.
In general, I agree. In this particular case, I'm not concerned.
If Apple were to change the implementation of +new to *not* do
+alloc followed by -init, many many bits of code would break.
Binary compatibility between release of Mac OS X is critical and,
thus, this particular behavior cannot change.
I'm afraid I don't understand that assertion at all. What does this
have to do with binary compatibility? Why did it *not* break
compatibility in the move from 10.4 (in which new does not invoke
alloc by default) to 10.5 (in which it does)?
I just checked all the way back to 10.1. The implementation was
+allocWithZone: NULL followed by -init until Leopard, when it moved to
+alloc followed by -init.
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. There is only one version of any given framework
on any given release of Mac OS X. As such, Leopard's Foundation /
AppKit has to remain compatible with prior implementations to the
point where just about all applications -- a handful have to be rev'd
mostly because they broke the rules, whether by bug or intentional --
remain compatible across releases of Mac OS X.
(There is an exception -- some frameworks will sometimes check to see
if a particular application is "linked for" a particular version of
the system and, as a result, will modify their behavior slightly.
This is generally done to preserve bugs that existed in previous
systems. For example, the AppKit might preserve a memory leak that
was present in Tiger or Panther simply because some third party apps
had worked around the leak with an extra -release and the now-fixed
version of the AppKit will cause those applications to break.)
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.
b.bum
_______________________________________________
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