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
