JEP 186: Collection Literals

Tue Jan 14 11:29:51 PST 2014

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