list literal gotcha and suggestion

[Reinier Zwitserloot]

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