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