Design for collections upgrades

Pavel Minaev int19h at
Tue Mar 8 16:59:33 PST 2011

On Tue, Mar 8, 2011 at 3:49 PM, Stephen Colebourne <scolebourne at>wrote:

> On 8 March 2011 23:23, Ola Bini <ola.bini at> wrote:
> >> A better argument against making filter() return a stream is that it's
> >> unexpected. The verb "filter" means "filter", not "create a stream
> >> that when later evaluated will filter." You can imagine users putting
> > I personally am a fan of this argument. I ended up using the past tense
> > for lazy sequences in Ioke for this specific reason. It becomes
> > immediately obvious if you're in strict or lazy-land based on the tense
> > of the method names. To Brian's argument, the type system will tell you
> > too, but that's not always apparent from reading a specific line of code.
> Sounds like a coding style I've used:
>  list.filter(predicate)  // alters list itself
>  list.filtered(predicate)  // returns a new list

It is a common pattern, but in this case the first version isn't in-place
filtering - it's also "return a new X". The difference between the two is
when the filtering does happen - before the return, or after.

I don't think that past vs present tense gives a good clue there, either. In
fact, using past tense for lazy ops also sounds like a misnomer because it
implies that the operation has already completed by the time method returns,
which is not the case.

I generally prefer the standard convention of map/filter/... compared to
.NET select/where/..., but it now strikes me that the latter naming is
indeed less ambiguous for the lazy case - it does not imply in-place
modification, nor does it carry a strong connotation of preserving the
source collection type.

Then again, what's wrong with the original Brian's code where you had to use
asLazy() on the collection to "enter the lazy land", where all operation
names are the same, but all effects are deferred inasmuch as possible? It
seems that intent indicated there clearly enough; are distinct names for
operations actually needed in that case?

More information about the lambda-dev mailing list