----- Mail original -----
> De: "Stuart Marks" <stuart.ma...@oracle.com>
> À: "Stephen Colebourne" <scolebou...@joda.org>
> Cc: "core-libs-dev" <core-libs-dev@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.ma...@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
