Re: [GDL2] NSAutoreleasePool/EOFault

[David Ayers]

Manuel Guesdon wrote:

> On Thu, 17 Mar 2005 14:56:06 +0100 David Ayers <address@hidden> wrote:
>
>
> > | 
> > | Please commit you fix for now.
>
>
> Done.

Thanks!

> > | >  >| 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).

But we don't need to exclude EOFault since it's using GSObjCClass and it 
as Richard said, if it ever were actually need to call class the 
optimization would become moot and it would send -release anyway.  So I 
don't think we have to do anything here for now.

> > | > 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.
Hmm. I don't really like the idea yet.  I think we should really try to 
avoid IMP caching where it doesn't have a clear measurable benefit and 
then think about the consequences everywhere we actually do need IMP 
caching and deal with them as they come up.  Punishing everyone else 
with extra tests and harder debugging doesn't seem like the right 
direction to me.  But I've not made up my mind yet on whether this may 
be worth it anyway.

Cheers,
David