RFC: draft API for JEP 269 Convenience Collection Factories

[Remi Forax]

----- Mail original -----
> De: "Stuart Marks" <stuart.marks at oracle.com>
> À: "Stephen Colebourne" <scolebourne at joda.org>
> Cc: "core-libs-dev" <core-libs-dev at openjdk.java.net>
> Envoyé: Samedi 10 Octobre 2015 01:11:09
> Objet: Re: RFC: draft API for JEP 269 Convenience Collection Factories
> 
> 
> 
> On 10/9/15 6:11 AM, Stephen Colebourne wrote:
> > On 9 October 2015 at 00:39, Stuart Marks <stuart.marks at oracle.com> wrote:
> >> 1. Number of fixed arg overloads.
> >
> > Guava follows this pattern:
> >
> > of(T)
> > of(T, T)
> > of(T, T, T)
> > of(T, T, T, T... elements)
> >
> > whereas the proposal has
> >
> > of(T)
> > of(T, T)
> > of(T, T, T)
> > of(T... elements)
> >
> > I'd be interested to know why Guava did it that way and what the trade offs
> > are.
> 
> I can't answer for the Guava guys, of course, but I can supply some
> additional
> background about why we chose this approach for our proposal.

I remember discussing this kind of things with Kevin Bourrillion something like 5 years ago.

There are several issues with:
  of(T)
  of(T...)

if called with null, the overload selected will be of(T...) and the compiler will emit a warning,
because it's not clear if of(null) should be called like this of((T[])null) or of(new T[]{null})
(for backward compatibility the former will be used by default).

but even without null, a code like this is ambiguous from the user perspective,
  String[] array = ...
  of(array)
should it returns a List<String[]> with the array as sole element or a List<String> with all elements contained in the array.

Rémi