JEP 186: Collection Literals

[Nick Williams]

Well at that point we might as well support "var":

var person = new Person();

And property assignment:

var person = new Person { Name = "Paul" };

Though that was only partially serious, my main point is that we seem to have drifted quite away from the originally discussion...

Nick

On Jan 17, 2014, at 7:43 PM, Zhong Yu wrote:

> Integer and int are essentially the same thing. But Person and String
> are very different. It is confusing that a String can be assigned to a
> Person; traditionally that implies that String is a subtype of Person.
> 
> `Person = new Person` does seem redundant. Maybe we can reach a compromise like
> 
>    Person person = new("Paul");
> 
> Zhong Yu
> 
> 
> On Fri, Jan 17, 2014 at 1:35 PM, Jonathan C. Ross
> <Jonathan.Ross at imc-chicago.com> wrote:
>> 
>> 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.
>