JEP 186: Collection Literals
Klaus.Malorny at knipp.de
Tue Jan 14 12:28:24 PST 2014
On 14.01.2014 20:33, Paul Benedict wrote:
> The other reason I prefer a unified syntax is so other types can
> participate in the syntax. Brian alluded to this first (kudos). I had this
> mind when I wrote my email (but didn't know such liberal uses were being
> entertained), and it would really be nice to allow such things. Then we can
> use such constructs for three-value tuples, n-value tuples, etc.
originally, I did not want to interfere the expert round with my layman ideas
any further, but I changed my mind, at least for the this next e-mail ;-). I
hope it is thematically not too far away from Brian's desires.
Well, one could define a generic syntax that can represent at least list-style
and map-style data sets. These are translated by compiler into calls to a
builder interface that is somehow provided by the desired type, e.g.
List<String> list = ArrayList#["a", "b", "c"];
is translated into:
ListBuilder<ArrayList<String>> lb = Internal.magicFunction (ArrayList.class);
// uses information from annotations to ArrayList
// or whatever in order to construct
// ListBuilder instance
lb.start (); // maybe with # elements to ease resource allocation
lb.add ("a"); // maybe with multi-argument methods instead
list = lb.getObject (); // result must be of type ArrayList<String>
This would avoid the limitation of the literals to the Java Collection Framework.
Syntax-wise, some automatic simplifications could be applied for multi-level
structures, e.g. a list of sets:
List<Set<Integer>> list = ArrayList#[HashSet#[1, 2, 3], [2, 3, 4], [3, 4, 5]];
^ ^ ^
0 1 2
i.e. for the element 1, the preceding type of element 0 would be reused, which
is HashSet, and the same applies to element 2. If no type is given at all, a
Java specific well-defined type is used (e.g. HashSet, ArrayList, HashMap),
derived from the type on the lhs.
As an alternative, the outer list builder (see above) could provide a
subordinate builder if no explicit builder is defined for an element. However,
this would likely reduce the flexibility and maybe also hard to perform some
compile time type checks. I guess nobody would like to see e.g. an
"OperationNotSupported" or a "ClassCastException" exception from a literal
construct. It would also be quite intransparent to the developer who uses the
But I have to admit that I am not really convinced of my own ideas...
More information about the lambda-dev