Fred Kiefer schrieb:
I only follow this discussion with out any deeper knowledge of the
subject, so my suggestion may be utter nonsense. But to me it seems
that
NSAutoreleasePool does the right thing. It seems wrong to me to
return a
different selector from +instanceMethodForSelector: than from
-methodForSelector:.
If one would call:
[[aFaultedObject class] instanceMethodForSelector:@selector(release)];
one would actually get the implementation of the unfaulted object.
Yet if one would call that method directly on the faulted object,
you'd
get undefined behavior (ie most likely some kind of memory
corruption if
ivars are being accessed before some other method happens to fire the
fault).
But what NSAutoreleasePool was doing is:
[GSObjCClass(aFaultedObject)
instanceMethodForSelector:@selector(release)];
When this optimization was introduced I had to add the
implementation to
EOFault even though it shouldn't be needed. But since most other code
never saw the EOFault class (as they call -class instead of
GSObjCClass()), didn't use +instanceMethodForSelecotor: but called
methods which would trigger forwardInvocation: (just like
methodForSelector: does) that didn't much matter.
Why cannot both methods on EOFault check whether is
is save to return the method from the un-faulted class and only then
return this method otherwise fault and return the method from the new
class.
The EOFault class method +instanceMethodForSelector: has no access to
the instance whos class was obtained by GSObjCClass(). It therefor
cannot have access to the actual class of the fault and therefor it's
methods. But even if it did, invoking those methods directly (i.e.
bypassing forwardInvocation:) will break the code.