JSR 335 Lambda Specification, 0.6.2

[Dan Smith]

On Mar 3, 2013, at 1:11 PM, Brian Goetz <brian.goetz at oracle.com> wrote:

> A few quick q's:
> 
> > Diff:
>> http://cr.openjdk.java.net/~dlsmith/jsr335-0.6.2-diff.html
> 
> Diff against which version?  0.6.1?

Yes, 0.6.1.

>>> Functional Interfaces: Renamed the term functional interface type
>>> to just function type
> 
> If we were to add structural function types in Java 10 or later, would this terminology become a problem?

I'm open to alternative suggestions.  The previous attempt, "functional interface type," didn't work, because the term needs to include some intersection types; generally, "foo interface type" is interpreted as "an interface with property foo, possibly parameterized or raw" -- so I was fighting against that intuition.

"Function descriptor" should also be part of this discussion -- it's inspired by the VM's use of "descriptor" to refer to the parameter and return types of a method, but it's a very specialized concept (for example, a VM "descriptor" is always erased), and I'm not sure it's wise to try to repurpose it here.  "Signature" probably doesn't work -- that refers to parameter types only (well, and type parameters) in JLS, and the generic equivalent of a descriptor+throws clause in the VM (oy).  Since a "function descriptor" is a kind of "type of a method" (JLS 8.2), it might make sense to use "function type" or "functional method type" here?

Some possible combinations of terms the might work:

- "Function type" is the general term for types that can be targeted by lambdas.  Among these are functional interface types, intersections involving function types, and [insert name here] (structural function types).  Separately, "function descriptor" can be renamed however is preferred.

- "Function type" is a structural function type.  A lambda can target a [insert name here], which may be a function type, a functional interface type, or an intersection involving a [insert name again].  Separately, "function descriptor" can be renamed however is preferred.

- "Function type" consists of the parameters, return, etc., of a method.  Functional interfaces "have" a function type (other interfaces and classes do not).  Syntax supports expressing certain function types directly.  Lambdas can target any type that "has a" function type, including functional interface types, intersections involving types that have a function type, and function types themselves.

>>> Default Methods: Removed support for an explicit package access
>>> modifier. Refined the definition of overriding to more accurately
>>> represent the intended behavior when the overriding method is
>>> inherited (mostly to account for package-access methods).
> 
> Did we ever circle back to compare the inheritance rules in the spec with the FD model?  I recall that there were definitely gaps in the super-call handling of FD -- are there any other known gaps for which we should at least call out differences, if not update FD itself?

(The changes I made here are strictly related to overriding by inheritance and package access.  So, outside of the scope of FD, I believe.  The goal was to preserve JLS 7 semantics while re-expressing and clarifying how overriding is defined.)

If I remember correctly, what was missing from FD was
- Acknowledgement that sometimes a superinterface is reached through a superclass
- Accounting for the possibility that, for a super call, an interface method may be overridden by a class method
- Treatment of plain 'super.m' when it refers to an interface method

I still have some notes to revisit some of this, since we weren't sure how to apply the restrictions on super calls to interface methods when there is a superclass involved.

—Dan