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.
We could define our own Iterable, in one of our packages, with the same
definition as java.util.Iterable.
However, it would not have the nice for-loop syntax, and we could spend
a lot of time building up workarounds for not being 1.5.
Patricia
