list literal gotcha and suggestion

[John Hendrikx]

Varargs constructors for the various Sets and Lists would have solved a 
lot of problems already and would also fit nicely with the call for 
standard utility methods in java.util/lang.  Any enhancement that gets 
rid of the Arrays.asList(...) construct would be most helpful.

Maps however would remain a pain to instantiate.  So a good syntax for 
creating maps or more generally, pairs or groups of values would 
alleviate that.  Personally I was thinking more along the lines of 
providing a constructor like this for Maps:

  public HashMap(Pair<K, V>... pairs);

With some new syntax to easily create Pairs:

  Pair<Integer, String> p = {1: "A"};

Resulting in:

 new HashMap<Integer, String>({1: "A"}, {2: "B"}, {3: "C"});

It's a bit more verbose than the proposed syntax, but it has the 
advantage of also offering a standard way for returning pairs of values 
(from a map) and for adding single entries:

  for(Pair<K, V> pair : map) {
  }

  myMap.add({4: "D"});

etc..

--
John Hendrikx


Greg Brown wrote:
> I know this proposal has already been approved for inclusion in Java  
> 7, but it really seems like it might not be worth the effort. Wouldn't  
> it be simpler to just add a varargs constructor to the collection  
> classes? To me, this:
>
> List<String> list = ["a", "b", "c"];
>
> isn't much better than:
>
> List<String> list = new ArrayList<String>("a", "b", "c");
>
> With the improved type inference feature, declarations such as this  
> will be even less verbose.
>
> I recognize that maps are trickier, but I still think that this:
>
> Map<String, Integer> map = new HashMap<String, Integer>(new  
> AbstractMap.SimpleImmutableEntry<String, Integer>("a", 0),
> 	new AbstractMap.SimpleImmutableEntry<String, Integer>("b", 1),
> 	new AbstractMap.SimpleImmutableEntry<String, Integer>("c", 2));
>
> is preferable to modifying the language for what (to me) seems like a  
> fairly marginal use case.
>
> Greg
>
>
> On Sep 29, 2009, at 5:53 AM, Stephen Colebourne wrote:
>
>   
>> Over the 1.4million LOC codebase I work on, I found 12 set literals.
>> We're not talking about large numbers. Interestingly, the majority of
>> these were constants, and may be more common than list constants.
>> There weren't any cases of parameter passing of a set literal.
>>
>> That said, I strongly dislike the confusion apparent here. We should
>> avoid new puzzlers if possible. I'd prefer
>>
>> List<String> list = {"1", "2", "3"} - List literal
>> Map<Integer, String> list = {1 : "1", 2 : "2", 3 : "3"} - Map literal
>> No set literal
>> (I don't think this conflicts with the array literals...)
>>
>> Perhaps there is also an argument for adding the static of methods to
>> construct mutable Set/List:
>>
>> Set<String> set = HashSet.of("1", "2", "3");  // mutable set
>> List<String> list = ArrayList.of("1", "2", "3");  // mutable list
>> List<String> list2 = {"1", "2", "3"};  // immutable list
>>
>>
>> One final thought. It would be possible to add a "method" to the  
>> list literal:
>>
>> Set<String> set = {1, 2, 3}.toSet();  // immutable set
>>
>> This approach would handle additional interfaces too:
>>
>> SortedSet<String> set = {1, 2, 3}.toSortedSet();  // immutable  
>> sorted set
>> MultiSet<String> mset = {1, 2, 3}.toMultiSet();  // immutable
>> multiset/bag (if added to JDK)
>>
>> Stephen
>>
>>
>> 2009/9/29 Reinier Zwitserloot <reinier at zwitserloot.com>:
>>     
>>> Scanning my codebase, they are quite rare. As the set literals are
>>> causing rather a lot of pain, let's see some proof before going too
>>> far down this road.
>>>
>>> Pain caused by set literals:
>>>
>>>  - ambiguity of {} - is that the empty set or the empty map?
>>>  - set/list confusion.
>>>  - the parser becomes quite a bit more complicated to handle the
>>> difference between sets and maps.
>>>
>>>  --Reinier Zwitserloot
>>>
>>>
>>>
>>> On 2009/29/09, at 10:02, Mark Thornton wrote:
>>>
>>>       
>>>> Reinier Zwitserloot wrote:
>>>>         
>>>>> new HashSet<>(["a", "b", "c"]);
>>>>>
>>>>> is too much effort in the rare cases where you need to initialize a
>>>>> set-typed parameter? This is java, not perl. Golfing isn't the end
>>>>> goal.
>>>>>
>>>>>           
>>>> Without scanning my codebase I wouldn't expect Set parameters and
>>>> fields to be rare. I use Set's quite frequently.
>>>>
>>>> Mark Thornton
>>>>
>>>>         
>>>
>>>       
>
>
>