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 14:15:45 -0500
On Feb 17, 2008, at 11:13 AM, Bill Bumgarner wrote:
On Feb 17, 2008, at 5:25 AM, Gregory Weston wrote:
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?
(1) Developer declares a subclass of NSObject that overrides, say,
+alloc
(2) Developer instantiates said class through +new
2a. Developer has made an error in assuming that new will invoke
alloc, in that the documentation makes no such promise, the framework
had no such behavior until less than 3 months ago, and that behavior
cannot be guaranteed even today.
(3) Apple changes the implementation of +new in, say, 10.9 to no
longer call +alloc
(4) Developer's application that had been compiled on, say, 10.4
and has run without recompilation on 10.4, 10.5, 10.6, 10.7 and
10.8 now breaks when double-clicked on 10.9
Incorrect. If the developer built on 10.4, using new to instantiate
their class did not invoke their override of alloc.
When Apple released Leopard, there was a general expectation -- a
general requirement -- that any application compiled/built on prior
releases of Mac OS X would work on Leopard.
True. I think it's an eminently reasonable expectation as long as
there were no unwarranted assumptions made. I assert that your
assumption that +new is guaranteed to invoke +alloc is unwarranted.
The documentation says that new act's *like* alloc. It does not
promise that it will achieve that by invoking alloc, in contrast to
the promise that it *will* invoke init.
Any application that does not, as per the above hypothetical
example, continue to work across a major OS release boundary or a
software update is considered to be a binary compatibility issue.
The only issue you've laid out is that a developer relied on
something that was not documented to be reliable and *cannot* be
guaranteed to be reliable. Kind of like the handful of developers who
had trouble with the 10.5 firewall because they made unwarranted and
incorrect assumptions about the extent of their ownership of the app
package.
... 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.
I'm not sure where your claim that +new was not implemented by
calling +alloc/+allocWithZone: followed by -init. I looked at the
source back to 10.1. +new was implemented as a call to +alloc or
+allocWithZone: followed by a call to -init since at least 10.1.
See what you're saying? +alloc *or* +allocWithZone:.
See the subject? +alloc. It does not say anything about +allocWithZone:.
See this code?
@interface MyTest : NSObject
@end
@implementation MyTest
+ (id)alloc
{
NSLog(@"allocating");
return [super alloc];
}
@end
@implementation MyObject
- (void)awakeFromNib
{
MyTest* a = [[MyTest alloc] init];
MyTest* b = [MyTest new];
[a release];
[b release];
}
@end
Guess how many times it emits "allocating" on 10.4. Hint: It's not
the same as 10.5.
I never claimed that "+new was not implemented by calling +alloc/
+allocWithZone:," so I'm not sure what yu hope to demonstrate by
saying that I did. What I claimed, and what is true, is that it is
not correct to say that "[Foo new] is exactly equivalent to [[Foo
alloc] init]." It's not true by default prior to 10.5, and it's not
reliable on any version of OS X. If you'd like to say "[Foo new] is
exactly equivalent to [[Foo alloc] init] as long as you're running
10.5-10.5.2, using no 3rd-party classes outside your control, did not
override +new in any of your classes, and are not writing a plugin to
code outside your control" I won't argue. But that's a much more
restricted statement than the one under discussion.
_______________________________________________
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