list literal gotcha and suggestion

[Lawrence Kesteloot]

I know this is a very basic question, but what are the use cases for
immutable list and map literals? I just looked through my largest
Python programs and my current 80,000-line Java tree and I don't see
any place where I'd use either.

I occasionally need to list a bunch of stuff (e.g., lists of
parameters returned by DataProviders in TestNG), but the array literal
syntax works for that.

Lawrence



On Wed, Oct 7, 2009 at 12:49 PM, Reinier Zwitserloot
<reinier at zwitserloot.com> wrote:
> I've only seen serious opposition to dumping set literals from one or
> two voices. As far as I can remember, we were pretty solidly
> converging on the idea of having just map and list literals, with a
> toSet() method to address places where you'd rather have a set, and
> adding in static factory methods to HashSet and ArrayList, which would
> create mutables (the literals create immutables).
>
> To this date I see no problem with this approach and I haven't heard
> any credible major issue with it, either, other than "Sets are
> important". Which nobody is denying, which is where the toSet() method
> comes in.
>
> Am I missing something and is there any proposal to get collection
> literals implemented in a manner compatible with the aims of coin that
> is significantly better (or even at the same level as) this proposal?
>
>
> The major point you're missing is the proposal to make list literals
> implement a to-be-named concrete implementation of java.util.List that
> has a few useful utility methods, including at least "toSet()". The
> reason being that:
>
> {1, 2, 3}.toSet();
>
> is a lot nicer than:
>
> Collections.unmodifiableSet(HashSet.of({1, 2, 3}));
>
>
> There was some discussion about a tiny detail - should we have of()
> methods that take varargs, should we have of() methods that takes a
> Collection (which you could then make with the list literal syntax),
> or should we just stick with the already existing copy constructors?
> As coin also includes the diamond operator this isn't as painful as in
> java6 - you'd have to write new HashSet<>({1, 2, 3}); if you wanted a
> mutable set with the first 3 positive integers in it. Then again,
> diamond is probably uglier than an of method. Then there's another
> tiny detail: Should these methods be called 'of', or 'newList'? If
> you're *NOT* using static imports, then 'of' is much nicer, but if you
> want to statically import these pseudo-constructors, 'of' is useless.
>
>  --Reinier Zwitserloot
>
>
> On 2009/07/10, at 19:40, Tomas Salfischberger - Celerity wrote:
>
>> Hi All,
>>
>> I have been reading this discussion passively for 87 messages, I think
>> we have come to the point where this will only result in a yes-vs-no
>> type discussion without converging to a possible solution?
>>
>> Trying to get back to the message that started this lengthy debate on
>> target typing, magic types and tricky situations for which proposed
>> solutions fail: Proposed List-literal syntax is [a, b, c] and proposed
>> Set-literal syntax is {a, b, c}. The debate started because of the
>> possible confusion between the two. There are multiple possible
>> solutions:
>>
>> - Use a single syntax for set, list and map: Seems like a lot of magic
>> and discussion whether this is possible. Maybe proof is in the code,
>> would it be possible to construct a proof of concept?
>>
>> - Drop Set-literals and use { } for lists: Lots of opposition because
>> Sets "should be used"
>>
>> Following up on the second solution, would it be a plausible
>> solution to
>> create just a List-literal which would result in an unspecified
>> implementation of the List-interface. Then introduce the proposed
>> of-methods? That would take away some of the opposition to removing
>> Set-literals as creating sets would still be possible, only with
>> slightly more work. An example of the result:
>>
>> ArrayList.of({1, 2, 2, 3});
>> LinkedList.of({1, 2, 2, 3});
>>
>> HashSet.of({1, 2, 3});
>> TreeSet.of({1, 2, 3});
>> LinkedHashSet.of({1, 2, 3});
>>
>> This would also be in alignment with the statement that Sets should be
>> used for performance reasons. When used for performance reasons I
>> would
>> expect the developer to consciously select the implementation with the
>> correct characteristics and thus not use just a simple (unspecified)
>> literal.
>>
>> For maps it would be possible to use the {1: "a", 2: "b", 3: "c"}
>> syntax
>> without confusion on what the type of that expression would be?
>>
>> Best regards,
>>
>> Tomas Salfischberger
>>
>>
>
>
>