JEP 186: Collection Literals

[Remi Forax]

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.

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

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

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

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

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