Re[2]: [GDL2] NSAutoreleasePool/EOFault

[Manuel Guesdon]

On Thu, 17 Mar 2005 14:56:06 +0100 David Ayers <address@hidden> wrote:

>| Manuel Guesdon wrote:
>| 
>| >  >| I agree with Richard, that this is all a bit worry some.  But by 
>design 
>| >  >| those two optimization simply don't work to well together.  I think we 
>| >  >| could implement the EOFault class method instanceMethodForSelector: to 
>| >  >| accommodate the NSAutoreleasePool optimization, at least temporarily 
>to 
>| >  >| unbreak GDL2.  
>| > 
>| > I agree.
>| 
>| Please commit you fix for now.

Done.



>| >  >| I'm still a bit unsure on how to deal with the methodForSelector: 
>class 
>| >  >| method.  But that's just because it looks like the issue seems 
>unsolvable.
>| > 
>| > Yes, it's not a simple probleme and I'm too not sure that there's a 
>perfect 
>| > solution.
>| > 
>| > Another idea is to have a list of class to exclude in a as simple (fast) 
>as we 
>| > can structure (like a c array) to store small number of class to exclude 
>| > from optimization but it will be non sttandard and slower.
>| 
>| The problem is, that you can't always identify the class.  If you have 
>| an unfaulted custom class you don't know whether it will ever be 
>| faulted.  And whether you want the fault's implementation or the objects 
>| implementation depends on the context.  For NSAutoreleasePool's release 
>| we're just lucky.

I was thinking about EOFault, not classes which can be faulted, as this is the 
class we get when we do a GSObjCClass(anObject).


>| > Another one could be to not use the EOFault class directly but an EOFault 
>| > derived dynamically created class for each kind of EOFault possible 
>| > class so the class returned by GSObjCClass will 'know' what it is and 
>| > could handle messages better (i.e. its release method can call EOFault 
>-release 
>| > if object is really a fault of real class -release if object is not a 
>fault) but it 
>| > introduce a kind of proxy which will be slower...
>| 
>| You mean verifying in the -release implementation of EOFault that the 
>| receiver is still a fault... and if not actually sending [self 
>| release]...  And a custom object's release implementation (well actually 
>| our (GDL2's) -release implementation of NSObject) would have to check 
>| whether we are actually a fault currently, and if so, send [self 
>| release]... 

Yes, something like that.


>| hmmm maybe it could work as long as no one overrides 
>| release.  But it it quite a hack and it would be applicable to retain 
>| and a few other methods also.  I'll spend some more time thinking about it.

We could also provide some macros to call at the beginning of methods to 
do the job but anyway, no perfect solution.

Manuel