Re: [Pyobjc-dev] Bug Fixed!!! Dealing with alloc / init oddities

[Bill B. <bb...@co...>]

On Friday, October 25, 2002, at 04:06 PM, Ronald Oussoren wrote:
> Bill,
>
> The 'fix' was not your change to 'objc_support.m', but the change to 
> 'selector.m' (the one I'm so unhappy about ;-()

Yes -- I undid the change in objc_support.m and committed the 
unmodified version.  Sorry.  Should have undid that.

> The problem is that NSMutableArray isn't really following the Cocoa 
> refcounting conventions. This can be demonstrated using a simple 
> Objective-C program:

That the NSArray class cluster uses a placeholder upon allocation isn't 
a violation of the Cocoa refcounting conventions -- it is just fallout 
from the design of the class cluster.   There is nothing that says that 
what is returned by +alloc must be  the same instance as whatever is 
returned by -init.

> Note that return value of the two calls of alloc is the same, and 
> different from the return value of the corresponding init calls. 
> Appearently 'alloc' just returns a kind of factory object, and 'init' 
> is the one that actually allocates memory.
> Further investigation shows that the return value of 'alloc' is a 
> 'NSPlaceholderMutableArray'. Actually it is probably that class and 
> not an instance of it. Both 'x->isa->name' and 'x->isa->isa->name' are 
> 'NSPlaceholderMutableArray', if 'x' where an object I'd expect the 
> second to be 'NSObject'.

The NSArray class cluster returns a placeholder [factory] for 
allocation because it does not yet have enough information to determine 
which private subclass will most efficiently hold whatever the 
developer is about to throw at it.

> I'm glad to find that the problem with NSArray is caused by a feature 
> of Cocoa and is not a memory corrupting bug in PyObjC itself. That 
> doesn't make it easier to actually fix it of course, but at least we 
> can now start to think about how to really solve this instead of 
> hunting down an elusive memory corruption
> error.

That the placeholder is both shared, but allows itself to be released 
to the point of destruction, would seem to be something that Apple 
would have wanted to avoid by simply overriding -release on the 
placeholder class and having it do nothing.   This would, at least, 
prevent an app from crashing in a bizarre fashion because the cached 
placeholder instance has blown up.

Then again, maybe they are playing interesting internal games with the 
retain count.

The implementation of the placeholder class itself does seem to be a 
bit odd.

b.bum