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.
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.
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.
Patricia
James Grahn wrote:
I should also add, we'd likely need to derive our own class extending
Iterable & Iterator to avoid losing existing MatchSet methods of
getSnapshot and getLease.
I don't see an immediate problem with this; a collection-backed
Iterable/Iterator would always have a null Lease, correct?
jamesG
On 1/18/2011 5:38 PM, James Grahn wrote:
It (finally) occurred to me that we can have our cake and eat it too in
this case.
We can have the sweet deliciousness of API symmetry and retain the
implementation advantages of remote iterator & collection by having both
take-multiple and contents return:
Iterable.
This would introduce more flexibility in the spec, allowing more design
decisions to be made by those implementing, while presenting a uniform
external return type to the users. (A relatively standard one at that.)
When I was looking at the remote iterator earlier, I was thinking it
would probably be best to have it implement Iterator and probably
Iterable anyway.
The only potential sour note is that Iterable is a 1.5 interface. So
that's come up again.
jamesG
