apply (original) (raw)

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 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-experts mailing list