Are function types a requirement?

[Alex Buckley]

You have summed up the situation perfectly.

Anonymous inner classes would be much better loved without the 'final' 
gotcha. I would hate for lambdas to fall into the same "What were they 
thinking?" bucket over a technically minor detail like function types. 
Furthermore, function types in themselves still leave Doug needing 
duplicate ParallelArrays to get fast primitive array implementations.

Counterpoint: one could say that function types + upgraded anonymous 
inner classes (without the 'final' restriction) + lambda conversion 
would be fine. No lambda expressions needed. No arguments over 'this'. 
Compatible with adding method references.

Let's remember that this OpenJDK project is an experiment, with a small 
mailing list (~150 people), and without interaction from many valued JCP 
partners. So I don't see the need to throw out function types today, 
barely six weeks after the project started being active.

Alex

Stephen Colebourne wrote:
> Recent threads have indicated the difficulties of adding function types 
> to the language.
> 
> - difficult/impossible to integrate with arrays (an omission that would 
> certainly be a surprise to many I suspect)
> 
> - difficult to integrate with varargs
> 
> - difficult to implement (various strategies suggested)
> 
> - difficult syntax choices (difficult to find something that is easy to 
> read, given Java's painful checked exceptions)
> 
> - debated invocation syntax - the func.() syntax
> 
> 
> One alternative is to omit function types from JDK 7, and only include 
> conversion to SAM interface types. It would be a compile time error to 
> declare a lambda expression/block that did not convert to a SAM.
> 
> Function types could then be included in JDK 8 if a valid approach was 
> available (ie. it gives the appearance of needing much more in depth 
> study than the timescale allows)
> 
> Pros:
> - reduces risk of making the wrong decision in the short JDK 7 time-frame
> 
> - avoids all the issues above (AFAIK)
> 
> - doesn't restrict adding function types later (we'd need some proof of 
> this)
> 
> - reduces the initial learning curve
> 
> Cons:
> - doesn't tackle the problem of fork-joins excess of interfaces, which 
> is declared as a major project goal
> 
> - results in multiple, incompatible SAM interfaces for the same concept
> 
> - no automatic handling of co/contra variance
> 
> 
> I therefore ask (in a positive way!) as to whether function types are a 
> fixed requirement of project lambda? Or whether the SAM-conversion-only 
> strategy would be considered for JDK 7? (My concern is to avoid the 
> experience of generic wildcards where it was rather rushed in at the 
> last minute by all accounts)
> 
> I'm really looking for a simple answer from Alex rather than a debate on 
> this...
> 
> Stephen
> 
> 
> 
>