JEP 186: Collection Literals

[Zhong Yu]

On Wed, Jan 15, 2014 at 11:04 AM, Per Bothner <per at bothner.com> 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.

There is no need for array literals; method+vararg is just fine

    String[] strings = array("a", "b", "c");

(of course this requires generics/vararg which java1.0 didn't have.)

Array literals (and, array types) are more of an oddity from today's
point of view; we should get rid of them if that were possible,
because their functions can be perfectly achieved with other general
purpose language devices.

List literals, or T literals in your example, have equally little
value. It creates a new burden for programmers - they now have two
very similar ways to do the same thing, and they have to waste their
brain power to make a choice. Two camps will emerge fighting each
other over whose syntax is better.

Zhong Yu


>
> --
>         --Per Bothner
> per at bothner.com   http://per.bothner.com/