Review request for initial lambda functions and utils

[Kevin Bourrillion]

(I have yet to look at the code because I'm new to this group and don't know
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 Predicates.isNull()
> 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. For
> 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 who
> don't really get wildcards, but should the standard libraries cater to
> methods declared to take Predicate<T> where they should take Predicate<?
> 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 Predicate<T>
are trying to get away without using the wildcards on their method
signatures that the language really dictates they *must*.  They always have
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 predicate
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" -- only
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).


-- 
Kevin Bourrillion @ Google
Java Core Libraries Team
http://guava-libraries.googlecode.com