Design for collections upgrades

[Collin Fagan]

If we had constructor references, we could just pass one for the collection
we want to use, even way early in the process. Each step would then have the
option of creating any number of correctly typed collections necessary to
get it's job done.

I know constructor references have been requested but I'm not sure if it's
on the list of features under consideration by the expert group.

Co*ll*in

(with 2 l's, not to be confused with Mr. Decker)


On Tue, Mar 8, 2011 at 7:05 PM, Sam Pullara <sam at sampullara.com> wrote:

> 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?
> >
>
>
>