list literal gotcha and suggestion

[Greg Brown]

I had actually suggested something very similar back in July:

http://mail.openjdk.java.net/pipermail/coin-dev/2009-July/002097.html

However, at this point I don't think I'd advocate any language changes  
associated with this feature. I think adding the varargs constructor  
(and/or unmodifiableList(), map, etc. methods) would solve this  
problem quite nicely within the existing Java feature set.

But that is just my 2 cents. The Project Coin selection committee  
disagrees with me.  :-)

Greg


On Sep 30, 2009, at 3:14 AM, John Hendrikx wrote:

> 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
>>>>>
>>>>>
>>>>
>>>>
>>
>>
>>
>