Re: [Foo new] vs [[Foo alloc] init]:

FROM : Gregory Weston
DATE : Sun Feb 17 20:15:45 2008

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.