On 11 Apr 2008, at 17:26, Quincey Morris wrote:
On Apr 11, 2008, at 08:07, Michael Ash wrote:
The obvious technique would be to stop trying to make the
optimization
implicit and to make it explicit and managed by the caller instead.
In
other words, you write your API so that it explicitly returns the
same
object every time you call -nextObject, just with a new state. Then
you have a copy method which the caller can use to get a new
unchanging object for the case where he wants to keep one around.
Furthermore, if the "new state" just consists of a pointer to a C
structure, the caller never needs to bother keeping the object
around, but can just keep the structure pointer.
That would be true, if you wanted to expose the underlying data
structure directly. I can think of many cases where that's
undesirable though.
Alternatively, since it's necessary to write a custom NSEnumerator
subclass for this, why not just write a new CEnumerator class that
returns 'nextStruct' instead of 'nextObject'? It's not like
NSEnumerator actually implements any behavior that you can inherit
anyway.
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".
(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.)
Kind regards,
Alastair.
--
http://alastairs-place.net
_______________________________________________
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]
