Updated State of the Lambda

[Howard Lovatt]

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.