Design for collections upgrades

[Sam Pullara]

The problem was that there wasn't any obvious way to know what the concrete type of the resulting collection would be in the eager case. Presumably people care what data structure is being used under the covers.

Sam

On Mar 8, 2011, at 4:59 PM, Pavel Minaev wrote:

> On Tue, Mar 8, 2011 at 3:49 PM, Stephen Colebourne <scolebourne at joda.org>wrote:
> 
>> On 8 March 2011 23:23, Ola Bini <ola.bini at gmail.com> 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?
>