JEP 186: Collection Literals
brian.goetz at oracle.com
Tue Jan 14 15:29:30 PST 2014
> The real question is "how far do we go." The original Coin proposal
> stopped at sets, lists, and maps (and had a different syntax for each.)
> But this seems kind of lame; why can't something that is
> List-like but
> not a java.util.List participate?
> Is there any real reason to restrict the proposal to implementing any
> specific interface? It seems preferable to able to specify some kind of
> recipe or factory for building an arbitrary concrete type out of a
> collection literal. This could then be associated with the class it
> constructs through a mechanism such as a ClassValue.
That's exactly what I meant by "how far do we go". The extremes of this
axis are "set/list/map/array only" at one end and at the other, a fully
general pluggable mechanism for initialization that could support things
like Json literals with nested target typing (i.e., a list-like literal
inside a Json list would be target-typed to a Json list), initialization
of JavaBean classes using map-like literals, static binding of map-like
literals to constructors (giving the appearance of named parameters,
presumably with some concept of symbol), etc. This feature could be
very small or very big.
Now, you might ask, why would we choose the simple thing when we could
choose the grand and abstract? To re-re-re-state the obvious, modifying
the language is insanely expensive, and I don't just mean it costs
Oracle a lot of money. Every new feature requires every developer to
learn it so they can read code; it needs to be documented and covered in
tutorials, books, and training. It affects tooling (like IDEs). It
requires specification, implementation, and conformance testing -- not
just for us, but for anyone who wants a conformant Java implementation.
Each feature interacts, potentially in surprising ways, with each
other. Each incremental feature moves us closer to collapsing under the
weight of complexity.
Just in this course of this thread we've already seen half a dozen grand
ideas thrown out in the vein of "while you're doing collection literals,
can you also do..." (e.g., operator overloading), as if it were just a
matter of decreeing it so, or even as if people think it just hadn't
occurred to us, and we only needed to be reminded. And every one of
these ideas competes with ever other one for attention.
So before jumping on the bandwagon for a given feature, ask yourself: if
we only got one more feature in Java in the next ten years, is this the
one you would want? If not, you probably should be advocating for
reducing, not expanding, its scope, or for junking it altogether.
Now, some features, like "enhanced integer literals" (i.e., 1_000_000),
are actually small enough that they can be tossed into the pot without
pushing much else out. But such features are few and far between.
For example, how long would you have been willing to delay Lambda to
make collection literals better? I suspect (and hope) the answer is
"none at all". It almost always is a choice of "this or something else."
> It would be a shame to privilege core library
> classes over third party ones in this regard.
This is a powerful consideration, and another aspect of my "how far"
question. The rational thing might actually be to do nothing here.
Because we may well have a choice of doing something that is assymmetric
and hacky, but small enough to actually do without upsetting the
applecart, or something that is symmetric and pleasingly abstract, but
not remotely as important as the things it might push off the plate.
More information about the lambda-dev