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

[Jonathan Finn]

> 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); }
> 

I was going to suggest one of:

	interface Action<T> { void actOn(T t); }

	interface Action<T> { void act(T t); }

	interface Action<T> { void action(T t); } // here 'action' is a verb. 

Jonathan


On 19 Jan 2013, at 13:19, 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
> 

Jonathan Finn
jfinn at boxoftricks.org