Updated State of the Lambda

[Brian Goetz]

I agree that restricting SAM conversion to interfaces would be simpler and cleaner.  However, it fails the "real world usefulness" test.  So unless there are serious show-stopping problems (other than just "something could go wrong"), I am taking this as a requirement.  

Your point (1) amounts to "there are risks!"  Yes, there are risks.  Life is risky.  There are also techniques to mitigate the risks.  This comes down to a risk/benefit call, and I don't see any reason why the risks win here.  

Your point (2) is focusing on a corner case of a corner case; self-referential lambdas occur infrequently.  Let's not let that tail wag the dog.  

Your point (3) is simply mistaken.  In 

>  Runnable r = #{ ... };

the variable r *is* a Runnable.  It is the lambda expression #{...} that is not.  Once you SAM-convert, the conversion target IS an instance of that SAM type.  

On Oct 20, 2010, at 1:04 AM, Howard Lovatt wrote:

> Hi Brian,
> 
> Taking each of your points in turn:
> 
> 1. Yes an IDE can help with the refactoring of inner classes to
> lambdas and the changing of this, however not everyone uses an IDE (I
> personally do but know many people who use a text editor or if they do
> use an IDE they use it like a text editor).
> 
> 2. I agree that abstract classes as SAM types are desirable, but the construct:
> 
>   AbstractClass ac = #{ ac.sam() };
> 
> will be confusing because people are used to qualifying with a class
> name, not an field/variable name. Also rather defeats the point of an
> inline definition since it must be on a separate line.
> 
> 3. Not defining what instanceof, getClass, etc. do is undesirable, consider:
> 
>  Runnable r = #{ ... };
>  List<Runnable> l = new ArrayList<>();
>  List<Runnable> cl = Collections.checkedList( l, Runnable.class );
>  cl.add( r ); // Oops - fails because r isn't a Runnable (its only
> treated as one by the type system - not by the JVM)
> 
> You get similar issues to the checkedList issue above with
> Serializable/Cloneable; you need, at times, to be able to check if an
> object is Serializable/Cloneable.
> 
> Cheers,
> 
> -- Howard.
> 
> On 20 October 2010 03:38, Brian Goetz <brian.goetz at oracle.com> wrote:
>>> I have some reservations about changing the type of this, particularly
>>> that it will make refactoring from Inner Classes to Lambdas and vice
>>> versa error prone.
>> 
>> That's a risk, but (a) most of the time the compiler will catch simply cut and paste bugs and (b) we expect IDEs to provide "refactor lambda to named inner class" refactorings, which can adapt / warn on code that uses 'this'.
>> 
>>> May I suggest a further couple of changes that
>>> might make refactoring more reliable:
>>> 
>>> 1. SAM types can only be interfaces (you must use an inner class if
>>> you want to inherit from and abstract class or class).
>> 
>> We explored this early on and concluded this was unsatisfactory.  It is quite common in the evolution of a project that interface-based SAM types evolve to be abstract classes when the need for "optional", rarely-used methods is encountered.  This conclusion was made on the basis of looking at specific code bases.  However, moving the cutoff just past "abstract classes with no-arg constructors" captures many more of the desirable cases and excludes relatively few.
>> 
>>> 2. The specification defines what all Object's methods do for a
>>> Lambda, in particular getClass, toString, equals, and hashCode, and
>>> how instanceof behaves, is a Lambda an instance of MethodHandle is it
>>> an instance of its SAM type?
>> 
>> Neither.  Lambdas expressions can be *converted to* references to SAM types.  It is not specified what they are; they cannot exist in any context other than one in which they will be converted.  So you cannot assume they are objects, or SAM types, or anything.
>> 
>> This turns out to be far less of a restriction than you might think.  (Think: what is the type of a method body?  Does it bother you that in all your years of Java coding, you've never had the need to ask this question?)
>> 
>> 
> 
> 
> 
> -- 
>   -- Howard.