river-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Patricia Shanahan <p...@acm.org>
Subject Re: Space/outrigger suggestions (remote iterator vs. collection)
Date Wed, 19 Jan 2011 07:54:32 GMT
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 

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.


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

View raw message