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.
_______________________________________________
Cocoa-dev mailing list (Cocoa-dev@lists.apple.com)
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:
http://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com
This email sent to [EMAIL PROTECTED]
