list literal gotcha and suggestion

[Kai Kunstmann]

Hey y'all

I've been following this discussion and the overall process of the
coin-project (unfortunatelly, only since a little after the proposal
periode). I'm just an ordinary developer who will eventually be using
the new features you guys are going to introduce to the Java language.
So far, I'm not too happy about it, which is why I'm sending this mail.

I support Mr. Gafter's opinion about the "lack of consideration for the
long-term evolution of the language", which is why I'm also very
concerned about the results of the coin proposals to be of beneficial
value (with all due respect).

About this particular issue: I reeeaaaally don't like the idea of a
language literal such as the proposed one to actually be some kind of
implementation of some interface, especially out of the java.util.*
package. Notice something? Yes, this is literals extending classes,
which is anything but syntactic sugar (as opposed to literals building
on top of interfaces, as with the enhanced for-each loop). Having this
said, I realize the proposal breaks one basic rule:

  Objects are created by the "new" operator.

The breaking of this rule is the true reason, why auto-boxing bugs
everyone. Don't repeat mistakes!

The strongest argument against this proposal is, however, that we don't
need an additional extra-special-super-plus syntax for something that
could be accomplished with no more than an ordinary factory method,
which would suit just fine in the java.util.* package (quote someone).


Iff any kind of "collection" literal, I would prefer struct-like
multi-type tuples similar to (one-type) arrays. A tuple would be
something like (but not the same as) a variable-generic-type Object
array with the generic-types bound to the corresponding indices for type
inference. Such tuples could then be used, e.g. for multiple return
values and as arguments to a static Map factory.

Suppose something like this:

  public static <K, V> HashMap<K, V> of([]<K, V> ... tuples) {
    HashMap<K, V> map = new HashMap<K, V>();
    for ([]<K, V> tuple : tuples)
      map.put(tuple[0], tuple[1]); // type inference by index
    return map;
  }

used like that:

  HashMap<Integer, String> map = HashMap.of({ 1, "one" }, { 2, "two" });
                 // or maybe ... HashMap.of([ 1, "one" ], [ 2, "two" ]);
                 // or even ...  HashMap.of(( 1, "one" ), ( 2, "two" ));
                 // ...so that "{..}" may be used for future closures

which is short for something like this:

  HashMap<Integer, String> map = HashMap.of(
      new []<Integer, String>{ 1, "one" },
      new []<Integer, String>{ 2, "two" });

( Yes, I just broke the creation-by-new-operator
  rule, but I promise it's barely an Object! )


Now, this is way too late and way too much for the coin-project, and it
will most certainly break something in the type-system anyway, so don't
consider it a proposal but just my two cents.

My basic message is the first few paragraphs: Don't have literals
inherit from classes! Don't have special purpose construction syntax!
Object's are created by the "new" operator! Vote for Republicans!



Kai Kunstmann



Am Mittwoch, den 30.09.2009, 13:02 -0700 schrieb 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.
>