apply

Doug Lea dl at cs.oswego.edu
Mon Dec 17 05:25:32 PST 2012


On 12/16/12 21:07, Brian Goetz wrote:

> Now, you might say "that's a stupid example" (and you might be right!) But, the
> "all different" rule allows for the possibility that this might actually be
> reasonable in some configuration; the "all same" rule ensures that this can
> never happen.

Penalizing everyone (in the sense of having to remember or rely on IDE
to remember which of the many nearly-synonymous names are used for
a given SAM) for the sake of allowing inadvisable and
work-aroundable usages seems like a questionable tradeoff.


>  I do find myself tripping over
> UnaryOperator.operate vs Function.apply since they're both just so functiony.

Right.


> And here's where there might be some good news for you. Since we currently have
>
>    interface UnaryOperator<T> extends Function<T,T>
>
> then it actually is quite reasonable for UnaryOperator to adopt the name from
> Function, since there is no way to implement UnaryOperator without implementing
> Function.  In which case some of the offenders -- Unary/BinaryOperator -- can go
> away.

Please.

Also, it is amusing that in current lambda repo,
Block has accept but BiBlock has apply. That's the one
that led to my "OMG I gotta stop this nonsense!" posting.

-Doug



More information about the lambda-libs-spec-observers mailing list