Review Request: CR#8001634 : Initial set of lambda functional interfaces

[Howard Lovatt]

General Comment
=============
For the collections framework there is a description of the whole framework (http://docs.oracle.com/javase/7/docs/technotes/guides/collections/index.html); why not do the same for the lambda framework and put a reference to the description in all the interfaces' and classes' Javadoc. This description would be a good place to talk about concurrency and side effects and to show suggested usage idioms. 

Overall Structure
=============
I will preface this comment saying that you might be considering doing this suggestion; but it isn't included at this stage because you are previewing a subset that excludes default methods etc. 

With the Collections Framework there are root interfaces, Collection and Map, and progressively there are more specific interfaces. This structure is very handy because it allows collections to be treated abstractly. Likewise it would be handy if the functions had Combiner at the top of the hierarchy. In particular:

public interface Combiner<L,R,V> {
    V operate(L left, R right);
}
public interface BinaryOperator<T> extends Combiner<T,T,T> {
    T operate(T left, T right);
}
public interface UnaryOperator<T> extends Combiner<T,Void,T> {
    default T operate(T left, Void notUsed) { return operate(left); }
    T operate(T operand);
}
public interface ZerothOperator<T> extends Combiner<Void,Void,T> {
    default T operate(Void notUsed1, Void notUsed2) { return operate(); }
    T operate();
}
public interface IntBinaryOperator extends BinaryOperator<Integer> {
    default Integer operate(Integer left, Integer right) { return intOperate(left, right); }
    int intOperate(int left, int right);
}
Similarly long and double versions. 
public interface IntUnaryOperator extends UnaryOperator<Integer> {
    default Integer operate(Integer operand) { return intOperate(operand); }
    int intOperate(int operand);
}
Similarly long and double versions. 
public interface Mapper<T, R> extends Combiner<T, Void, R> {
    default R operate(T t, Void notUsed) { return map(T t); }
    R map(T t);
}
public interface IntMapper<T> extends Mapper<T, Integer> {
    default Integer map(T t) { return intMap(t); }
    int intMap(T t);
}
Similarly long and double versions. 
public interface Predicate<T> extends Mapper<T, Boolean> {
    default Boolean map(T t) { return test(t); }
     boolean test(T t);
}
public interface Block<T> extends Mapper<T, Void> {
    default Void map(T t) { apply(t); return null; }
    void apply(T t);
}
public interface Factory<T> extend ZerothOperator<T> {
    default T operate() { return make(); }
    T make();
}

Float Variation
===========
There are int, long, and double specialisations; float specialisations would also be useful (particularly for graphics). Also, some day maybe the JVM will use the graphics co-processor (which are much faster for float than double). 

Typo
====
The last section of package-info "All functional interface implementations are expected to:" seems to be a typo. Presumably this file was only partially completed. 

Keep up the good work,

  -- Howard. 

Sent from my iPad

On 01/11/2012, at 7:16 AM, Mike Duigou <mike.duigou at oracle.com> 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/
>