list literal gotcha and suggestion

[Jonathan Gibbons]

Neal,

I agree that ':' may not be the best choice of separator for these 
so-called pair literals, and that there must be some other token we can use.

We could also use JSR 308 annotations to achieve some amount of compile 
time checking of varargs argument lists. For example,
class HashSet {
static HashSet<T> of(@Unique T...)
}

-- Jon



Neal Gafter wrote:
> On Wed, Sep 30, 2009 at 11:31 AM, Jonathan Gibbons <Jonathan.Gibbons at sun.com
>   
>> wrote:
>>     
>
>   
>> +1 for the suggestion regarding HashSet.of, ArrayList.of, etc.
>>
>> This whole discussion over which type of brackets to use for which
>> literal illustrates well why Java Is Not C.  Java's design point is to
>> go for clarity over obscurity at the cost of typing a few more
>> characters.  The fact that there can be such an ongoing discussion here
>> illustrates why these literals are such a bad idea, when there are such
>> clear and relatively simple alternatives.
>>
>> That all being said, I think map literals *are* a good idea, just
>> because there is no reasonable alternative that can be used today.  And
>> even then, you really only need a syntax for a "pair", as in Expression
>> ":" Expression.  If you had that construct, then you could easily write
>> HashMap.of(1: "1", 2: "2"), or TreeMap.of(1: "1", 2: "2"), etc
>>
>>     
>
> I agree that a solution along these lines is a better approach for these
> literals.  However, I don't think the binary ":" operator is the best way to
> introduce a pair literal.  Besides the ambiguity in the second position of a
> ?: expression (which can be resolved by precedence), this conflicts with the
> most likely syntax for named parameters*.
>
> This is an example of an ongoing problem with the Coin design process.
> There seems to be a lack of consideration for the long-term evolution of the
> language.  Many of the Coin proposals (including accepted ones) conflict
> with reasonable (and likely and worthwhile) future directions.  In other
> words, they may be local improvements in the language design space, but they
> are not always working toward global maxima.
>
> Cheers,
> Neal
>
> * Incidentally, I take issue with parts of Alex Buckley's analysis of the
> design space for named
> parameters<http://blogs.sun.com/abuckley/entry/named_parameters>.
> He sets up some strawman designs and then shows how they fail to support
> named parameters with reordering.  We added support for named parameters in
> version 4.0 of the C# language, including support for reordering, and our
> experience is that the change is quite beneficial.  Alex's analysis
> demonstrates that the design space requires more exploration before
> committing to a particular design for Java.
>
>