On 11/01/2012 10:43 AM, David Holmes wrote:
[...]
package-info.java
* <em>Functional interfaces</em> provide typing for lambda methods.
lambda methods? Do you mean lambda expressions?
"non-defaulted" is a horrible term. Isn't it simply abstract? Seems to
me that "abstract default" should not be permitted and that default
wipes out any implicit abstract. That way a default method is not an
abstract method, while an abstract method is what it always has been:
a method signature with no implementation.
I agree that a single abstract method is a better term here.
Nitpicking, Java 8 allows static methods in interface so non-default
doesn't mean abstract but abstract or static methods.
Cheers,
David
Cheers,
Rémi
On 1/11/2012 6:16 AM, Mike Duigou wrote:
There's a large set of library changes that will be coming with
Lambda. We're getting near the end of the runway and there's lots
left to do so we want to start the process of getting some of the
more stable pieces put back to the JDK8 repositories. We've spent a
some time slicing things into manageable chunks. This is the first
bunch. We'd like to time-box this review at one week, since there are
many more pieces to follow.
The first chunk is the basic set of functional interface types. While
this set is not complete, it is enough to be able to proceed on some
other pieces. This set contains no extension methods (we'll do those
separately) and does not contain all the specializations we may
eventually need.
The specification is limited; most of the interesting restrictions
(side-effect-freedom, idempotency, stability) would really be imposed
not by the SAM itself by by how the SAM is used in a calculation.
However, some common doc for "how to write good SAMs" that we can
stick in the package doc would be helpful. Suggestions welcome.
Elements of this naming scheme include:
- Each SAM type has a unique (arity, method name) pair. This allows
SAMs to implement other SAMs without collision.
- The argument lists are structured so that specializations act on
the first argument(s), so IntMapper<T> is a specialization of
Mapper<R,T>, and IntBinaryOperator is a specialization of
BinaryOperator<T>.
In order to get the most useful feedback out of this review, we'd
like to ask you follow the following guidelines for the review:
- We are time-boxed at one week. (until Nov. 7th)
- Please review the whole bunch in a single message if possible,
rather than in bits and pieces. It is far easier to extract useful
feedback from one complete review than from a dozen partial ones.
- Please wait a few days before replying to other people's reviews!
We want to keep the discussion on-topic to maximize the useful review
content. It is far too easy for the discussion to spiral off into
minutia and lose sight of the goal -- which is to provide useful
feedback on the API we're asking for feedback on.
http://cr.openjdk.java.net/~mduigou/8001634/2/webrev/
