On 1/19/2011 2:54 AM, Patricia Shanahan wrote:
I don't think we should commit to a single class doing both Iterable and
Iterator. An Iterable is already committed to being able to supply an
Iterator on demand, but often the Iterator implementation is better done
as a private class member of the Iterable. Note that an Iterable needs
to be able to supply a new Iterator each time its iterator() method is
called.
Excellent point.
And quite worthy of further consideration, considering each iterator
involves remote interaction. If Iterable would lull the user into more
expensive usage patterns, it's worth considering keeping it to an
Iterator, though it would be nice to have an Iterable with its language
support.
Even MatchSet could have an implementation that merely iterates over a
collection, if we're desirous of its checked exceptions. So a unified
return type and broader spec would still be possible in that case.
Something to mull, at least.
I'm not sure what you are saying about combining Iterator and the
MatchSet features. My inclination would be to keep each interface simple
and clean. Many classes will implement Iterable and appropriate
interfaces representing the snapshot and lease capabilities.
Agreed.
I was shooting from the hip a bit yesterday, having just had the
realization that Collection vs. Remote Iterator is best addressed with a
higher abstraction. Thanks for the refinements.
As you can probably guess from the length of this reply, I'm back from
Egypt and have a full keyboard, not just an iPhone.
Welcome back.
Patricia
jamesG
