JEP 186: Collection Literals

Tue Jan 14 11:33:45 PST 2014

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.

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