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: Mon, 18 Feb 2008 08:11:23 -0500
On Feb 17, 2008, at 6:47 PM, Hamish Allan wrote:
On Feb 17, 2008 7:15 PM, Gregory Weston <email@hidden> wrote:
See what you're saying? +alloc *or* +allocWithZone:.
See the subject? +alloc. It does not say anything about
+allocWithZone:.
See this code?
[...]
Guess how many times it emits "allocating" on 10.4. Hint: It's not
the same as 10.5.
Your argument would be somewhat stronger if your code looked like
this:
@implementation MyTest
+ (id)allocWithZone:(NSZone *z)
{
if (z && z != NSDefaultMallocZone())
NSLog(@"allocating in some way not equivalent to calling plain
alloc");
return [super allocWithZone:z];
}
@end
In other words, +new may not call +alloc, but if it calls
+allocWithZone:
Which is promised where?
with exactly the same effect,
It won't be exactly the same effect if a developer decided the prior
behavior of new - that it did *not* invoke alloc - was reliable and
leveraged that presumed distinction when they overrode alloc. Can you
not imagine someone saying, "I'd like alloc to do something special,
and new to still be available to achieve the default behavior," and
getting burned when their users started moving to Leopard? You and
Bill would apparently say it was a bad assumption and they got what
they deserved - and I'd probably agree - but that assumption is not
definitively worse than the one we're talking about. It hinges on
exactly the same error: Someone looked inside the black box and
decided that it wasn't going to change.
the point is moot.
I'm going to direct your attention to the subject line and the
proposition that launched this debate as I did for Bill. The question
is not about the relationship between new and allocWithZone:. It's
about the relationship between new and alloc, which changed
significantly in October.
You might think of +allocWithZone: as being the "designated allocator"
(pre-Leopard, at least) -- you would always override that rather than
+alloc.
You might think of it that way, but you'd have no formal reason to do
so. The fact that alloc invokes allocWithZone: or that new invokes
either of them is an implementation detail not exposed anywhere in
the documentation or interface. Relying on unpromised implementation
details is anathema to OO design. You can do it if you like, but
encouraging others to do so, or telling them that it's reliable today
when it isn't, is inappropriate. That would tend to accelerate the
onset of the alleged binary compatibility issue that Bill wants to
avoid.
_______________________________________________
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