JEP 186: Collection Literals

[Zhong Yu]

On Tue, Jan 14, 2014 at 1:33 PM, Paul Benedict <pbenedict at apache.org> wrote:
> The other reason I prefer a unified syntax is so other types can
> participate in the syntax. Brian alluded to this first (kudos). I had this
> mind when I wrote my email (but didn't know such liberal uses were being
> entertained), and it would really be nice to allow such things. Then we can
> use such constructs for three-value tuples, n-value tuples, etc.

So we'll see C++ like implicit constructor calls?

    Person person = ["Paul"];

It is a little terrifying.

Zhong Yu


>
>
>
>
> On Tue, Jan 14, 2014 at 1:29 PM, Jochen Theodorou <blackdrag at gmx.org> wrote:
>
>> If I follow that train of thought, then I see the following (ignore syntax
>> please):
>>
>> HashSet<> set = [1,2,3] //#1
>> LinkedList<> list = [1,2,3,4] //#2
>> MyFavoritStruct struct = [a,b,c] //#3
>>
>> That means, the rhs is only a kind of compile time tuple and gets its real
>> meaning only through the lhs. The compiler could for example transform #1
>> into: HashSet<Integer> set = new HashSet<Integer>(1,2,3). Meaning the line
>> #1 is valid if there is a fitting constructor (or helper method). And it
>> would be easy for the user to let his structures fit in here (#3). But for
>> example Object o = [1,2,3] is not valid then.
>>
>> I think leveraging the constructor for that has a lot of heated discussion
>> potential. And besides that bigger nested structures will easily become a
>> hurdle. But I wanted to speak out, what seemed to lay on your tongue here
>> in my eyes ;)
>>
>> Though, you may not have meant that, because List<...> l = [1,2,3] would
>> then not be valid, unless you go through a (static) helper method defined
>> in List. And the discussion what exact type l will have will be
>> interesting... started here already actually. And I think there will be no
>> "fits all" type.
>>
>>
>> Am 14.01.2014 18:02, schrieb Brian Goetz:
>>
>>> And, we have now reached our quota of syntax discussion on this topic.
>>> No more, please!  Such discussions get in the way of the important
>>> questions like:
>>>
>>>    - what does this feature *mean*
>>>    - what should the limits of this feature be
>>>    - how does this map to bytecode
>>>
>>>  Problem is that you need to differentiate list and set (and map
>>>> possibly).
>>>>
>>>
>>> This need not be done syntactically.  We now have precedent and
>>> machinery for using /target typing/ here.  Let's assume the syntactic
>>> problems will be solved when we figure out what this feature ought to be.
>>>
>>> For example, the two lambdas below are syntactically identical, but the
>>> type system knows what they need to be converted to:
>>>
>>>     Function<String, Boolean> f = s -> s != null;
>>>     Predicate<String> g = s -> s != null;
>>>
>>> The same is true for distinguishing linear collections like arrays,
>>> lists, and sets.
>>>
>>> The real question is "how far do we go."  The original Coin proposal
>>> stopped at sets, lists, and maps (and had a different syntax for each.)
>>>    But this seems kind of lame; why can't something that is List-like but
>>> not a java.util.List participate?
>>>
>>>
>>> On 1/14/2014 11:19 AM, Paul Benedict wrote:
>>>
>>>> I think you could likely achieve all those with curly braces. You'll have
>>>> the help of type inference during assignment (list vs set) plus you can
>>>> nest values whenever you need tuples (maps).
>>>>
>>>>
>>>> On Tue, Jan 14, 2014 at 10:16 AM, Artur Biesiadowski <abies at adres.pl>
>>>> wrote:
>>>>
>>>>  Problem is that you need to differentiate list and set (and map
>>>>> possibly).
>>>>>
>>>>> Few examples from existing languages
>>>>>
>>>>> Groovy:
>>>>>
>>>>> List  [1,2,3]
>>>>> Set   [1,2,3] as Set
>>>>> Map   ["a":1, "b":2]
>>>>>
>>>>> Xtend
>>>>>
>>>>> List  #[1,2,3]
>>>>> Set   #{1,2,3}
>>>>> Map   #{"a"->1, "b"->2}
>>>>>
>>>>> Scala
>>>>>
>>>>> List  Array(1,2,3)
>>>>> Set   Set(1,2,3)
>>>>> Map   Map("a"->1, "b"->2)
>>>>>
>>>>> C#
>>>>>
>>>>> List  new List<int> {1,2,3}
>>>>> Set new HashSet<int> {1,2,3}
>>>>> Map   new Dictionary<string,int>  { {"a":1},{"b":2}  }
>>>>>
>>>>>
>>>>>
>>>>> Regards,
>>>>> Artur Biesiadowski
>>>>>
>>>>> On 14/01/2014 16:30, Paul Benedict wrote:
>>>>>
>>>>>> I would like to see Java have one way of doing initialization with a
>>>>>>
>>>>> series
>>>>>
>>>>>> of values. C11/C++11 decided that curly braces was the way to go. So I
>>>>>> would agree with Moshe we should favor curly braces over any new
>>>>>> syntax.
>>>>>>
>>>>>>
>>>>>> On Tue, Jan 14, 2014 at 8:34 AM, Millies, Sebastian <
>>>>>> Sebastian.Millies at softwareag.com> wrote:
>>>>>>
>>>>>>  I would certainly expect it to be an immutable list, and I believe the
>>>>>>> proposal of having collection literals makes most sense in the context
>>>>>>>
>>>>>> of
>>>>>
>>>>>> persistent collections. This would be in keeping with evolving Java
>>>>>>>
>>>>>> towards
>>>>>
>>>>>> a more functional and parallel-friendly programming style, which
>>>>>>> entails
>>>>>>> embracing immutability. In contrast, what's to be gained from a
>>>>>>> shorter
>>>>>>> version of Arrays.asList() ?  -- Sebastian
>>>>>>>
>>>>>>> -----Original Message-----
>>>>>>> From: lambda-dev-bounces at openjdk.java.net [mailto:
>>>>>>> lambda-dev-bounces at openjdk.java.net] On Behalf Of Moshe Sayag
>>>>>>> Sent: Tuesday, January 14, 2014 2:52 PM
>>>>>>> To: lambda-dev at openjdk.java.net
>>>>>>> Subject: Re: JEP 186: Collection Literals
>>>>>>>
>>>>>>> 1. What is the exact meaning of:
>>>>>>>
>>>>>>> List<Integer> list = #[ 1, 2, 3 ];
>>>>>>>
>>>>>>> Will 'list' be an ArrayList, a LinkedList or an immutable list?
>>>>>>>
>>>>>>> 2. Java already has the curly brackets {...} to construct an array.
>>>>>>>
>>>>>>> int[] array = { 1, 2, 3 };
>>>>>>>
>>>>>>> How will the new literal go with it?
>>>>>>> Will we have:
>>>>>>>
>>>>>>> int[] array = #[ 1, 2, 3 ];
>>>>>>>
>>>>>>> What about
>>>>>>>
>>>>>>> List<Integer> list = { 1, 2, 3 };
>>>>>>>
>>>>>>>
>>>>>>> Moshe
>>>>>>>
>>>>>>>
>>>>>>> On Tue, Jan 14, 2014 at 2:17 AM, <mark.reinhold at oracle.com> wrote:
>>>>>>>
>>>>>>>  Posted: http://openjdk.java.net/jeps/186
>>>>>>>>
>>>>>>>> - Mark
>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>> Software AG – Sitz/Registered office: Uhlandstraße 12, 64297
>>>>>>> Darmstadt,
>>>>>>> Germany – Registergericht/Commercial register: Darmstadt HRB 1562 -
>>>>>>> Vorstand/Management Board: Karl-Heinz Streibich
>>>>>>> (Vorsitzender/Chairman),
>>>>>>> Dr. Wolfram Jost, Arnd Zinnhardt; - Aufsichtsratsvorsitzender/
>>>>>>> Chairman
>>>>>>>
>>>>>> of
>>>>>
>>>>>> the Supervisory Board: Dr. Andreas Bereczky -
>>>>>>> http://www.softwareag.com
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>
>>>>>
>>>>>
>>>>>
>>>>
>>>>
>>>
>>
>> --
>> Jochen "blackdrag" Theodorou - Groovy Project Tech Lead
>> blog: http://blackdragsview.blogspot.com/
>> german groovy discussion newsgroup: de.comp.lang.misc
>> For Groovy programming sources visit http://groovy-lang.org
>>
>>
>
>
> --
> Cheers,
> Paul
>