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 07:53:06 -0500
On Feb 17, 2008, at 6:05 PM, Bill Bumgarner wrote:
On Feb 17, 2008, at 2:28 PM, Gregory Weston wrote:
Or you could just not assume that something which hasn't been
explicitly stated in the docs is guaranteed. That's what I've been
trying to say: The only promise the documentation makes about new,
alloc and allocWithZone is that they're peers. It doesn't say a
peep about any of them invoking any of the others to achieve that
equivalence. That lack of explicit promise - the utter inability
to make such a promise in general - is why it's wrong to say
without a whole lot of caveats that one technique is precisely
equivalent to another. Looking at the implementation of a method,
rather than the interface, as it exists today and saying "you can
count on this" is an outright rejection of one of the core
concepts of OO.
You can draw that conclusion if you want.
In light of the documentation, the binary compatibility
requirements, and the implementation for at least the past 6 years
-- if not the past 14 -- it would seem a rather pessimistic
conclusion.
The documentation supports me more than you, the binary compatibility
"requirements" don't exist, and the implementation aside from being
irrelevant only supports your reading since October. Yes, it *is* a
pessimistic stance, but that's the appropriate way to read such
things. An API doc is a first cousin to a standards document; what
isn't said is as important as what is and, in particular, if a
behavior isn't promised as reliable then relying on it is an error.
You were correct earlier when you noted that its in Apple's interest
to support correctly written programs, and historically they've done
that to a fault - I've seen them let things linger so long between
deprecation and removal that people decided Apple was kidding and
started using them again. But they've also not been terribly
forgiving of developers who relied on something that was never
documented as reliable. The behavior we're talking about here falls
into that latter category.
There is not a peep anywhere in the documentation that says alloc
*will* invoke allocWithZone: or that new will invoke either of them.
That lack of guarantee carries more weight than the implementation at
any given moment. The fact that the implementation changed in a
potentially significant way last October should scream about the
importance of not making that assumption. What happens to the
developer last year who assumed the then-current implementation of
new was reliable and leveraged that to intentionally make alloc
meaningfully different than new? Horrible design, IMO, and the
assumption is only part of it, but it's completely legal. Are you
going to claim that their assumption that new would always invoke
allocWithZone: directly is somehow less valid than your implication
today that it's always going to invoke either of alloc... methods?
+alloc is a cover for +allocWithZone: with a NULL zone. Not
that you would know that from the documentation, unfortunately.
Which means, like the current behavior of new, that's an
implementation detail that shouldn't really be relied on.
Hardly the point.
An odd comment, given that the validity of assumptions seems to be
precisely the point.
If you are overriding +alloc for whatever reason, you better had
override +allocWithZone:, too.
The real point is that there's no formal requirement that you do so.
It only becomes an issue if you make unwarranted assumptions about
the implementation.
_______________________________________________
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