Let's please rename Block to Receiver before it's too late

[Joe Bowbeer]

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<T> { void accept(T t); }
>
> -Doug
>
>