list literal gotcha and suggestion

Tomas Salfischberger - Celerity t.salfischberger at celerity.nl
Wed Oct 7 10:40:11 PDT 2009


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




More information about the coin-dev mailing list