Design for collections upgrades

[Yuval Shavit]

Hi all,

I'm just an observer here, and not quite an expert on these issues -- though
I am familiar with the concept of lambdas (and looking forward to them,
which is why I joined the list). I hope I can provide semi-outsider input.

I generally view a new aspect of a language as somewhere to be a bit careful
and read at least the javadocs before I get started, so I don't think
there's anything wrong with defaulting to lazy evaluation as long as that's
specified. Someone familiar with lambdas is going to look for whether
they're evaluated lazily or eagerly, and someone who's not is going to be
reading the lambdas/filtering/mapping tutorials anyway, so they don't even
have to know that eager evaluation is a possibility -- just teach them as a
lazy evaluation mechanism.

In other words, I wouldn't worry *too* much about confusing people with the
lazy/eager distinction. My preference would be a lazy-evaluated Stream which
I must explicitly toList/toMap at the end (with an instance of my choosing).
If possible, I'd like the toList/Map to be parameterized on the type of
instance, so that I can do:

HashMap<K,V> asHash = myStream.toMap( new HashMap<K,V>() );
TreeMap<K,V> asHash = myStream.toMap( new TreeMap<K,V>() );

Thanks,
Yuval

On Thu, Mar 10, 2011 at 1:57 PM, Rémi Forax <forax at univ-mlv.fr> wrote:

> I agree.
>
> Rémi
>
> On 03/10/2011 07:56 PM, Pavel Minaev wrote:
> > So if I call filter on a TreeSet reference, then I get a TreeSet; but
> > if I upcast it to Set and call filter, I get HashSet?
> >
> > I think it's too subtle, and likely to go unnoticed. Especially since
> > common practice in Java code is to type variables as relaxed as
> > possible, even for locals (i.e. Set rather than TreeSet).
> >
> > This also changes the usual conventions for collection operations,
> > where the precise semantics of the operation is defined by the dynamic
> > type of the collection, not static type of the reference. For example,
> > if I call add() on a List reference which refers to an ArrayList, I
> > know that the element is added to the end of collection, and that
> > complexity is amortized constant time. But with this proposal for
> > filter() etc, that would no longer be true - static type of reference
> > would define behavior.
> >
> > If there's no way to implement it such that it depends only on the
> > dynamic type of object, then I think it would be better to have a
> > single uniform behavior for all collections - and that would have to
> > be lazy, so that you can build eager (with collection type explicitly
> > specified) on top of that.
> >
> >
> > On Thu, Mar 10, 2011 at 3:32 AM, Alessio Stalla
> > <alessiostalla at gmail.com <mailto:alessiostalla at gmail.com>> wrote:
> >
> >     Well, extension methods are polymorphic, is that right? Then, you
> >     could have a different extension method per Set implementation, and a
> >     default one for Set that uses HashSet. If such an extension method
> >     existed, it should not be tied to filter in particular; I'm thinking
> >     of a generic newInstance() method. It could in fact be generalized
> for
> >     Collection.
> >
> >     Alessio
> >
> >
>
>
>