Review Request: CR#8001634 : Initial set of lambda functional interfaces
forax at univ-mlv.fr
Thu Nov 1 11:46:32 UTC 2012
On 11/01/2012 10:43 AM, David Holmes wrote:
> * <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.
> 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
>> 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.
More information about the core-libs-dev