list literal gotcha and suggestion

Kai Kunstmann Kai.Kunstmann at combase.de
Thu Oct 8 06:21:33 PDT 2009


Am Donnerstag, den 08.10.2009, 10:09 +0200 schrieb Ola Bini:
> Kai Kunstmann wrote:
> > Am Mittwoch, den 07.10.2009, 17:46 -0700 schrieb Lawrence Kesteloot:
> >>> http://www.google.com/codesearch?hl=en&lr=&q=ImmutableList.of|ImmutaleSet.of|ImmutableMap.of|Arrays.asList\(\w%2B,\w%2B+lang:java&sbtn=Search
> >>>
> >>> Seems like all sorts of configuration/static data/quick and
> >>> dirty/unittest/mock/etc types of syntax would benefit.
> >> That search returns 800 files out of a total of 11,300,000. That's one
> >> file in 14,125, or 0.007%.
> >>
> >> I would be against a feature which (1) has such an unclear correct
> >> specification; (2) provides so little advantage over a static
> >> ArrayList.of() and HashSet.of(); and (3) helps only one file in
> >> 14,125.
> >>
> >> On the other hand, the idea (proposed twice in this discussion) of
> >> have a pair literal seems much more widely useful, and would allow
> >> HashMap.of().
> > 
> > 
> > A struct-like tuple literal of any arbitrary (immutable) size would
> > cover even more use-cases, e.g. multiple return values in methods.
> 
> Not necessarily. Tuples are generally not iteratable (Python being the 
> exception). Also they don't actually match Collection<T> since they have 
> several different types. Tuples doesn't really solve any of the 
> problems, and they would have to have different semantics than existing 
> collections, which means larger incisions in the language.
> 

Tuples are not supposed to implement any kind of interface just like
arrays do, and they are not a candidate for the proposed list/set/map
literal. Their intent is to allow for a neat map factory method (entries
are 2-element tuples). List and Set factories can already be implemented
with the current language features.

Tuples are to be understood as arrays of elements with different types.
The type of each element/slot would be bound to the index and encoded in
the generic type parameter of a tuple. Arbitrarily sized tuples would
then require variable type parameters (which is not an option, I guess).
The runtime-type of any tuple would simply be Object[] or an array type
of the most specific type in common.


public static <K, V> HashMap<K, V> of([]<K, V> ... entries) { ... }

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


public []<Integer, Long, BigInteger> getNumbers() {
  return { 1, 2l, BigInteger.valueOf(3l) };
}

[]<Integer, Long, BigInteger> numbers = getNumbers();
Integer integer = numbers[0];
numbers[2] = BigInteger.valueOf(479l);

for (Number number : getNumbers())
  doSomethingWithNumber(number);

> 
> Cheers



More information about the coin-dev mailing list