Let's please rename Block to Receiver before it's too late (original) (raw)

Joe Bowbeer joe.bowbeer at gmail.com
Sat Jan 19 08:20:48 PST 2013

Action is too common in UI frameworks, including Android. And it is not parameterized. It is pretty far down on my list, below Block. Block is now neutral for me. Procedure is slightly positive. Everything else so far is below Block.

I agree with your criticism of Sink. I would not expect forEach to accept a Sink. This seems like an awkward mix of terms. On Jan 19, 2013 5:20 AM, "Doug Lea" <dl at cs.oswego.edu> wrote:

On 01/18/13 21:36, Brian Goetz wrote:

OK, OK, if people really, really hate Block, I would still consider Sink. Sink is the opposite of Source. We could rename Supplier to Source, and rename Block to Sink. Leaving the method names the same (accept and get.)

"Sink" is nice in the Stream framework, which is a plus in encouraging people to use it, but not in other common contexts where the main property to convey is that it is a possibly side-effecting action, as opposed to a Function. Does everyone else prefer "Action" as best possible name? If so, would we be willing to reconsider rejecting it because of Swing conflicts? The interactions do not seem to be all that bad: Swing programmers would never encounter problems as pure lambda-users (they need not import java.util.functions.Action or otherwise use the type.) So the only ones impacted are those who write lambda-accepting Swing methods, which do not yet exist. And to help a bit further, we could keep the method name as "accept", to reduce conceptual conflict with the conventions surrounding "perform" in Swing. interface Action { void accept(T t); } -Doug

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