list literal gotcha and suggestion

[Neal Gafter]

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.