Re: EOFault / NSAutoreleasePool

[Fred Kiefer]

Richard Frith-Macdonald wrote:
> 
> 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.
> 

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:. 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. This is clean and will work with any version of GNUstep base or
any other clean implementation of Foundation. What EOFault currently
does is rely on implementation details and this is usually asking for
trouble.

As I said, I only look at this from the outside.

Fred