Re: Efficient object wrappers and GC
Re: Efficient object wrappers and GC
- Subject: Re: Efficient object wrappers and GC
- From: Jean-Daniel Dupas <email@hidden>
- Date: Fri, 11 Apr 2008 19:57:28 +0200
Le 11 avr. 08 à 19:27, Quincey Morris a écrit :
On Apr 11, 2008, at 09:51, Alastair Houghton wrote:
It doesn't, but you might conceivably have methods that take an
NSEnumerator and do something with the objects it returns. Hence
the utility of "nextObject".
Ah, I see - simultaneous cake-having and cake-eating. :)
Isn't this problem similar to the GC-finalize problem, where you
can't safely do most object resource releasing in finalize, so you
have to do it earlier. Maybe the answer is the same, you give the
object an "i'm done with you" method that the user of the object
calls. After that, you would be able to cache and re-use the object.
(IOW, I guess, re-invent reference counting for the object.)
It's not a very elegant solution, but the "i'm done with you"
pattern is sort of in GC class design already.
(Actually, NSEnumerator *might* have one such useful behaviour... I
haven't tried it, but I wonder if the base class implements the
fast enumeration protocol by calling -nextObject repeatedly? Which
isn't the best way to implement fast enumeration, to be sure, but
it might still be useful sometimes.)
I think you must be right. IIRC, there's nothing to stop you using
fast enumeration syntax on a NSEnumerator whose underlying object is
not fast-enumeration conformable.
NSEnumerator is an abstract class. That's probably what the default
implementation do, but most of the enumerators returned by Cocoa
collection probably override this behavior._______________________________________________
Cocoa-dev mailing list (email@hidden)
Please do not post admin requests or moderator comments to the list.
Contact the moderators at cocoa-dev-admins(at)lists.apple.com
Help/Unsubscribe/Update your Subscription:
This email sent to email@hidden