JEP 186: Collection Literals

[Samir Talwar]

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

> On 01/15/2014 06:44 PM, Samir Talwar wrote:
> > 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.
>
> It depends how you define silly.
> What I wanted to say is just that collection literal should not be more
> complex than adding several overloads. And I fear that this is not
> possible.
> And the warning is not an unchecked warning but a varargs warning, and
> for of() it can be disable by using @SafeVarargs.
>

You're right. Sorry for the mix-up. I'm not sure what you mean by "more
complex" though. Do you mean the code required in APIs to support
collection literals? (If not, ignore the next bit.) I don't think there's
really a comparison to be made here; one exists purely to fill a language
hole, and one to hook into a language feature that would be otherwise
unavailable.

 >
> > 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.
>
> The question was more, not to restrict keys to be String only but
> to acknowledge that most of the keys will be String.
>

And I don't think this is true. When using string keys in JavaScript,
Groovy, etc. this is done because strings are no less safe than, for
example, enum values in a dynamically-typed language. In Java, etc. the
rules are different. Enum values offer no real penalty and a whole load of
compile-time benefits in most cases (i.e. where the keys are known ahead of
time in options maps and the like). While I'm not sure that strings won't
be more popular, I'd argue that's probably down to sloppiness and shouldn't
be encouraged. Obviously, any type is a candidate for a map key, but I'd be
upset if it was assumed to be a string and only processed as something else
if there was some extra magic syntax (for example, `[(key): value]` in
Groovy).

>
> >
> > 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.
>
> you want to be able to do a diamond in a cast ?
>

Not exactly. Often that's too late. For example, if I'm assigning to a
variable of the type `List<Runnable<Integer>>`, then I can't just assign
`[new DoThatThing(), new DoThatThing()]`. Nor can I cast it to
`ArrayList<Runnable>` later, as it's already of the type
`List<DoThatThing>`, and we can't vary the generic type. It needs to be
done at construction time. Something like `new ArrayList<> [1, 2, 3]` would
be more preferable, because then I can type `new ArrayList<Runnable> [x, y,
z]`.

>
> >
> > 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).
>
> I just say that we give up to try to find a common interface for
> injecting values for something more specific to stream.
>

I don't know much about this. What would be the problems with using
collectors?


>
> >
> > 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.
>
> regards,
> Rémi
>

And thanks again for humouring me. :-)

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