Re: [GDL2] NSAutoreleasePool/EOFault

[David Ayers]

David Ayers wrote:

> David Ayers wrote:
>
> > Manuel Guesdon wrote:
> >
> > > + (IMP) instanceMethodForSelector: (SEL)aSelector
> > > {
> > >  if (aSelector == 0)
> > >    [NSException raise: NSInvalidArgumentException
> > >                format: @"%@ null selector given", 
> > > NSStringFromSelector(_cmd)];
> > >  /*
> > >   *        Since 'self' is an class, get_imp() will get the instance 
> > > method.
> > >   */
> > >  return get_imp((Class)self, aSelector);
> > > }
> [snip]
>
> I guess all methods which currently wouldn't fire the fault, could 
> return EOFault's implementation (like release) and the others should 
> return the fault handler's targetClass implementation... but if 

[snip]

actually that's moot, as the EOFault class doesn't know about the 
instance, so we have no fault handler.

But back to NSAutoreleasePool, it currently uses GSObjCClass which will 
give it the EOFault class.  If it would have used -class, it would have 
obtained the object's class.  In this case EOFault is indeed preferable 
as it intends get the faults implementation of release and invoke it. 
If this release happens to dealloc the object, the fault will be cleared 
and dealloc is then called with the original isa.  So I guess we're safe.

I think I'll add some comments in NSAutoreleasePool explaining that 
GSObjCClass is actually not merely a performance issue but that sending 
-class would break GDL2.

Otherwise you can go ahead and commit your EOFault patch.  But we should 
keep in mind that caching implementation pointers for EO's is extremely 
risky.

Cheers,
David