Proposal: Collection Literals
jjb at google.com
Tue Mar 31 08:14:38 PDT 2009
I think the confusion between set literals and array literals is overblown.
So far as I know, the only context in which it can occur is a nested array
initializer on the right hand side of an array declaration. If you want
arrays, you typically want them "all the way down." So the proposed
solution of banning collection literals in array initializers on the right
hand side of array declarations seems like a perfect solution to this corner
Of course it is possible to directly use collection factories with varargs
(such as Arrays.toList), but you lose the conciseness, especially for maps.
Similarly, we don't need array-like access to collections: we can continue
using set, get, and put. But it people want the succinctness of array-like
access to collections, then they probably want the succinctness of
collection literals too.
As for reified generics, I'm still waiting for a code example where the
proposed approach will cause trouble.
On Tue, Mar 31, 2009 at 7:56 AM, Kris Nuttycombe
<kris.nuttycombe at gmail.com>wrote:
> Given the possibility of confusion between set literals and array
> initializers, how much worse would it be simply to provide vararg
> constructors, in the various collection classes? Similarly, why not
> just some additional vararg factory methods in Collections that can be
> used to produce the immutable versions?
> I realize that the syntax isn't quite as terse as what this proposal
> suggests, but I think it avoids the issues with reified types and
> would not represent a substantial deviation from the current state of
> the libraries.
> The only place where this wouldn't work is for map literals; however,
> if a Pair literal were introduced as has been suggested elsewhere then
> this problem could be easily resolved.
More information about the coin-dev