Are function types a requirement?

[Stephen Colebourne]

Alex, thanks for the reply. I think we all agree that we don't want
any "What were they thinking?" outcome!

Based on this, I may (if it proves sound) suggest an alternative
option to function types in a few days.

Stephen


On 18 February 2010 02:13, Alex Buckley <Alex.Buckley at sun.com> wrote:
> 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
>>
>>
>>
>>
>
>