On 13 Mar 2008, at 08:45, David Ayers wrote:
David Ayers schrieb:
On 11.03.2008, at 19:37, David Ayers wrote:
We took percautions due to (the old) NSAutoreleasePool optimization:
* It's a temporary fix to support NSAutoreleasePool optimization
But now that Richard has committed that "fix" we'd also have to
implement methodForSelector: ...
Actually, I'm not sure what to do here...
Well I could revert the 'fix'.
I assumed that it was safer to call -methodForSelector: on an object
than -instanceMethodForSelector: on a class, since any implementation
of the former would have more information to work with (knowing
details about the instance) in cases where the underlaying class was
implementing a proxy to some other object.
Of course, in an ideal world every class *ought* to have a correct and
reliable implementation of both methods ... I was just trying to go
for the option which I thought most likely to be reliable in practice.
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.
I'm happy to revert the change ... but at the same time I think
EOFault should have properly working implementations of all the basic
methods of NSObject and NSProxy. However, I have no knowledge of the
complexity of EOFault, so I don't know how much work that would be ...
Just let me know what you want me to do.
_______________________________________________
Gnustep-dev mailing list
[email protected]
http://lists.gnu.org/mailman/listinfo/gnustep-dev
