Multiple SAMs for same concept

[Pavel Minaev]

On Thu, Jul 15, 2010 at 4:34 PM, Stephen Colebourne
<scolebourne at joda.org> wrote:
> One problem noted with the removal of function types is that multiple
> SAMs with the same signature are not compatible. For example:
>
> http://gee.cs.oswego.edu/dl/jsr166/dist/extra166ydocs/extra166y/Ops.Generator.html
> http://guava-libraries.googlecode.com/svn/trunk/javadoc/com/google/common/base/Supplier.html
> http://google-guice.googlecode.com/svn/trunk/javadoc/com/google/inject/Provider.html
>
> Having these different incompatible definitions is problematic, for
> example when the developer has created a library of reusable
> implementations implementing one SAM, and then wants to use them using
> another (eg. a newly added JDK SAM).
>
> Given the method:
>  private void process(Generator<String> gen) { ... }
>
> the most recent draft SotL would allow the following two choices for conversion:
>  Supplier<String> supplier = ...
>  process( {-> supplier.supply()} );  // manual conversion to a Generator
>  process( supplier#supply() );  // using method ref to manually
> convert to Generator
>
> While the two solutions are not terrible, they are less than ideal. I
> would argue that the ideal would be:
>  process(supplier);  // auto-boxed from Supplier to Generator

Such "autoboxing" (since no boxing happens here, I'd rather call it
"autowrapping") wouldn't preserve object identity. I think it would be
very confusing to pass a reference to object, only to receive a
reference to a completely different (as in, r1 != r2) object on the
other side - especially without any explicit casts or other indication
that something unusual is going on.

This wasn't a problem with primitives because they don't have their
own object identity

> One compromise option I came up with was:
> process( supplier# );

This looks more reasonable.