JEP 186: Collection Literals

[Samir Talwar]

I've wanted to chip in to this thread all day. Now I finally have time. :-D

Remi: Overloads for `MyCollectionType.of(…)` are just pushing the work onto
the API designer. We should be able to do better than that. This sort of
thing is duplicated all over Guava too (I think in that case it was to
avoid unchecked warnings), and it's silly to expect everyone designing a
collection to do the same.

Klaus: Agreed. Strings are fine in dynamically typed languages, but when we
have static typing, I'd much rather use something the compiler can check. I
imagine that, just like in most JavaScript applications, most cases will
expect a relatively small number of keys that are known ahead of time.

I am very much of the opinion that the concrete type of the object
shouldn't be dictated. I think it should maintain a similar style to
lambdas; that is that the type is determined by the context (left-hand
side, parameter type, etc.). I would like to see something better than a
cast (which is generally very long when generics get involved) for
occasions where the concrete type is ambiguous, as this is going to happen
much more often than with lambdas.

I'd also like to avoid binding certain styles to specific interfaces; not
all of us use List, Set and Map every day. One notable exception is the
pcollections library, which defines persistent equivalents with interfaces
such as PVector, PSet, PMap, etc. and is a pretty good example of something
that others have hinted they'd like to see in the core Java library. To
that end, I'd like for every type to have the option of providing a builder
(could we re-use Collector, as Remi hints at?). I know there's the
possibility people will abuse this to make Java work like C++ but honestly,
I don't think there's much danger. Most people are pretty good at following
conventions, even if they're terrible (Java beans spring to mind).

Finally, I think it's pretty clear that we need two distinct styles: one
for list-like collections and one for map-like ones. I'm a pretty big fan
of Groovy's `[a, b, c]` and `[a: 1, b: 2, c: 3]`. I don't think there's an
advantage to a specific syntax for sets because of the above.

Cheers,

— Samir.



On Wed, Jan 15, 2014 at 5:14 PM, Remi Forax <forax at univ-mlv.fr> wrote:

> On 01/15/2014 06:04 PM, Per Bothner wrote:
> > On 01/15/2014 03:44 AM, Zhong Yu wrote:
> >> On Tue, Jan 14, 2014 at 7:17 PM, Per Bothner <per at bothner.com> wrote:
> >>> For example, one could define:
> >>>
> >>> T v = { e1, ..., en}
> >>>
> >>> as syntactic sugar for:
> >>>
> >>> TB tmp = T.make_builder();
> >>> tmp.add(e1); ..; tmp.add(en);
> >>> T v = tmp.build();
> >> How is this any better than
> >>
> >>       T.of(e1, ..., en);
> >>
> >> ? I don't see how the literal syntax helps code writers or code
> >> readers in this case.
> > I can think of two reasons:
> >
> > (1) Target-typing means you don't have to redundantly specify T:
> >
> > T v = { e1, ..., en};
> >
> > vs
> >
> > T v = T.of(e1, ..., en);
> >
> > (2) Using the T.of form requires allocating an array,
> > which is then thrown away.
> >
> > I don't think (2) is a major justification. (1) may not
> > be enough to justify a new language feature by itself,
> > though one could argue it's a natural extension of the
> > existing syntax for arrays.
>
> I disagree for (1), if you take a look to java.util.EnumSet by example,
> you will see that there are multiple overloads of 'of' to avoid to allocate
> an array in the common cases.
>
> Rémi
>
>
>
>