Review request for initial lambda functions and utils

[Kevin Bourrillion]

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
tailored to.


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
> 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).
> >
>
> 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
> holes
> 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.
>
> Rémi
>
>
>


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