JEP 186: Collection Literals

[Zhong Yu]

On Thu, Jan 16, 2014 at 3:54 PM, Jonathan C. Ross
<Jonathan.Ross at imc-chicago.com> wrote:
>
>>> Library-based solutions for maps are less good.
>>
>> But would be better if/when we have tuples/value types.
>>
>
>
> Now, there’s a feature that I definitely jump on a bandwagon for: tuples.  I would most certainly prioritise tuples over collection literals, precisely because it makes it so much easier to implement fluent collection libraries.  With type-safe, fixed-arity tuples as a language feature, it would be a relatively minor step to add syntactic sugar for (un-?) boxing tuples into collections (or any other object for that matter).  I don’t find Zhong Yu’s example of:
>
>         Person person = ["Paul”];
>
> that terrifying if there is a
>
>         public Person(Tuple<String>)
>
> constructor defined somewhere.  Or, heck,
>
>         @Implicit public Person(String name);

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.


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

>
>
> How to implement fixed-arity, type-safe tuples in a transparant fashion without something like C++11’s variadic templates or Scala’s Tuple1<T1>, Tuple2<T1,T2>… is a different matter.  Maybe invoke dynamic will save the day here too.
>
> -- Jonathan Ross
>
>
>
>
> ________________________________
>
> 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.