|
From: | David Ayers |
Subject: | Re: [GDL2] NSAutoreleasePool/EOFault |
Date: | Sat, 12 Mar 2005 21:43:15 +0100 |
User-agent: | Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.7.5) Gecko/20041217 |
David Ayers wrote:
David Ayers wrote:Manuel Guesdon wrote:+ (IMP) instanceMethodForSelector: (SEL)aSelector { if (aSelector == 0) [NSException raise: NSInvalidArgumentExceptionformat: @"%@ 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
[Prev in Thread] | Current Thread | [Next in Thread] |