Currently GDL2 would first fire the fault and then return the method
of
the selector. Yet for the case of NSAutoroleasePool (which is merely
supposed to call release), we do not want to fire (and we don't if
+instanceMethodForSelector: was called as it was previously).
When -methodForSelecotor: is called for other optimizations we do want
to fire (and currently do).
But now we would really have to look up which selector is being asked
for to decide which one should case the fault to fire.
This was not so apparent with +instanceMethodForSelector: because we
had
this hack for NSAutoreleasePool and most other optimizations used
-methodForSelector: which caused the fault to fire and return the
selector of the real object.
Unfortunately this change seems to be part of the unstable release.
IIRC, the Debian packages are based on the stable branch? Then I'd
like
to leave GDL2 as is (i.e. not implement -methodForSelector:) and
require
the stable branch for the GDL2 release. Of course I'd also like this
patch to be reverted for trunk and unstable branch.
Now if debian bases it's packages off the unstable branch... then I'd
really like to see bug fix release soon. I guess I'd volunteer to do
that...
I would want to add another special handling. EOFaults are indeed not
standard ObjC constructs that require special treatment (Probably like
NSProxy also). They try to be transparent objects but there are some
rules. Just like one isn't allowed to send certain methods to
NSAutoreleasePool instances, EOFaults are also special. I don't think
these optimizations should be allowed to have such an impact on the
semantics other features. I think we had a good compromise with
+instanceMethodForSelector: (but we my still need to improve on that
within GDL2). But asking us handle -methodForSelector for an
optimization seems to be rather tough.