JEP 186: Collection Literals

[Jonathan C. Ross]

On Jan 16, 2014, at 6:46 PM, Zhong Yu <zhong.j.yu at gmail.com> wrote:

> So are we going to allow
>
>    Person find()
>        ...
>        return "Paul";
>
> or
>
>    void save(Person person){ ... }
>    ...
>    save("Paul");
>
> ?
>
> This sound too dangerous. It most likely will hurt readability.

Dangerous?  Applied judiciously, it would be no worse than primitive autoboxing, which I definitely think aids readability.  If it was implemented naively, it would perhaps be dangerous for performance (just like primitive auto boxing).  But with proper byte code support (perhaps John Rose’s value-type approach?), one could eliminate the expense of both user-defined and intrinsic autoboxing.  Otherwise I would see no danger.  If you are afraid of syntactic ambiguities, you could require that the r.h.s. is a tuple literal, so:

        Person p = ( “Paul” );

(substitute your brackets of choice.  I have grown accustomed to Python and Scala’s parentheses for tuples, so that is my preferred notation. Curly braces would also make sense given the precedent of array initializers and C++’s initializer_list).

Given this literal assignment syntax, I think automatically mapping the tuple elements to constructor arguments would lead to a very nice coding experience indeed (c.f. initializer_lists in C++11 in absence of initializer_list constructors). I don’t see any situation where it would lead to ambiguities or lack of clarity.

>
>>
>> works for me as well.  But is it really necessary if you can just write:
>>
>>        Map<String, Integer> m = ImmutableMap.of((“First”,1), (“Second”, 2));
>
> How about using an infix operator, which saves two symbols per tuple.

In this example I had envisioned it actually being an array of pairs being passed in, but I guess you could add the ( . : . ) or ( . -> . ) shorthand for pairs too.  Ooh…. named arguments anyone?




________________________________

The information in this e-mail is intended only for the person or entity to which it is addressed.

It may contain confidential and /or privileged material. If someone other than the intended recipient should receive this e-mail, he / she shall not be entitled to read, disseminate, disclose or duplicate it.

If you receive this e-mail unintentionally, please inform us immediately by "reply" and then delete it from your system. Although this information has been compiled with great care, neither IMC Financial Markets & Asset Management nor any of its related entities shall accept any responsibility for any errors, omissions or other inaccuracies in this information or for the consequences thereof, nor shall it be bound in any way by the contents of this e-mail or its attachments. In the event of incomplete or incorrect transmission, please return the e-mail to the sender and permanently delete this message and any attachments.

Messages and attachments are scanned for all known viruses. Always scan attachments before opening them.