Functions#constant signature

[GoogleCodeExporter]

Enhancement request/suggestion/idea

Perhaps instead of
  public static <E> Function<Object,E> constant(@Nullable E value)

Declare
  public static <F,T> Function<F,T> constant(@Nullable T value)

--Reason
1. Expand the possible usages of this method.  Function<Foo,Bar> can often
be used where a Function<Object,Bar> cannot. 

2. This reads very naturally to my eye
  Function<Foo,Bar> f = Functions.constant( aBar );

--Impact
1. Any callers who have explicitly set the type arguments by saying
something like Functions.<List>constant( new ArrayList() ) will need to be
modified.  Calls using implicit types will not need to be modified.

(note, everything else below this point is sort of stretch looking for
potential downsides)

2. Input type validation:
  Function<Foo,Bar> f = Functions.constant( aBar );
  Function confused = f;
  confused.apply("love me or hate me);

Should we throw a ClassCastException in this case?  Current behavior can
never throw one.  I vote to maintain that. 

3. Equals 
  Function<Foo,String> x = Functions.constant("x");
  Function<Bar,String> y = Functions.constant("x");
  x.equals(y); // true
For myself, I think that's fine, since
  List<Integer> x = Lists.newArrayList();
  List<String> y = Lists.newArrayList();
  x.equals(y); // true

Original issue reported on code.google.com by gil...@gmail.com on 8 May 2009 at 6:38

[GoogleCodeExporter]

The signature is intentional. (We discussed the issue at greater length than any
other issue in the entire library.)

Show me a place where "Function<Foo,Bar> can be used where a 
Function<Object,Bar>
cannot" and, 9 times out of 10, I'll show you a broken API, which neglected the
wildcards it was obligated by the language to use.  If that API can't be fixed 
-- or
you're that other 1 out of 10 -- a cast is very easy:

  @SuppressWarnings("unchecked")
  Function<Foo, Bar> f = (Function) Functions.constant(aBar);

Impact:
1. that is a true concern. when users are forced to use GETPs* their code gets 
very
ugly; we don't want to make it worse.

2. there is no way to throw CCE because the type information has been erased.

3. yes, it is fine.

*Goddamn Explicit Type Parameters

Original comment by kevin...@gmail.com on 8 May 2009 at 6:50

[GoogleCodeExporter]

Original comment by kevin...@gmail.com on 11 May 2009 at 5:10

• Changed state: WontFix

[GoogleCodeExporter]

OK.  thanks.  

Original comment by gil...@gmail.com on 11 May 2009 at 8:10