Review request for initial lambda functions and utils
kevinb at google.com
Tue Aug 9 13:40:19 PDT 2011
I really don't understand this, but I can easily say that your compiler
sounds like anything but a *typical* user project, which JDK APIs should be
On Tue, Aug 9, 2011 at 1:31 PM, Rémi Forax <forax at univ-mlv.fr> wrote:
> On 08/09/2011 08:29 PM, Kevin Bourrillion wrote:
> > (I have yet to look at the code because I'm new to this group and don't
> > where to find it.)
> > On Tue, Aug 9, 2011 at 9:55 AM, Colin Decker<cgdecker at gmail.com> wrote:
> >> I'm curious about cases such as Predicates.IS_NULL and
> >> where there is both a public constant of type Predicate<Object> and a
> >> public
> >> method that returns Predicate<T>. For one thing, I find the existence of
> >> both fields and methods for these standard functions kind of awkward,
> >> particularly when there's both a field and a method for the same thing.
> >> another, is it really a good idea to provide a method returning a
> >> Predicate<Object> as a Predicate<T>? I realize there are many people
> >> don't really get wildcards, but should the standard libraries cater to
> >> methods declared to take Predicate<T> where they should take
> >> super T>? Or is there some other reason for this?
> > I strongly recommend that Predicates.isNull() NOT follow Guava's example
> > here. Return a Predicate<Object>. Users who want it to return
> > are trying to get away without using the wildcards on their method
> > signatures that the language really dictates they *must*. They always
> > the option to cast-and-suppress if they get into a pickle (we call that a
> > "safe contravariant cast", provided that the user is certain the
> > can never be subsequently cast to any type that is *not* contravariant on
> > T).
> > 90% of Guava's APIs use wildcards and type parameters "judiciously" --
> > when they are needed so as to *allow a method to be invoked* in all the
> > circumstances it should be -- but do not add extra wildcards and type
> > parameters that *also* allow the user to "massage" the return type of the
> > method just because they want to. I have never regretted this approach
> > (although I do sometimes regret having to explain it over and over and
> > over).
> Hi Kevin,
> You have to know that I've lost several Karma point because of you.
> Last year, I had to write a compiler for a DSL used to abstract some graphs
> with a runtime based on Guava.
> It was so painful to generate Java codes that use Guava that
> we eventually switch to another library.
> The DSL was statically typed so it was easy to know the type of each
> expression but
> because Guava doesn't work if you set explicitly the type arguments,
> I had to rely on the inference mechanism of javac
> (in fact the one specified in the Java spec) which as you know has some
> At some points, the code to try to explain to Guava which types I wanted
> was bigger than all other parts of the compiler, I just give up
> and use a simpler API.
> The Java generics spec is already complex so why creating an API
> which is harder to use by putting some extra fences.
Kevin Bourrillion @ Google
Java Core Libraries Team
More information about the lambda-dev