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

[Remi Forax]

On 01/19/2013 02:19 PM, Doug Lea 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); }

Writing event broadcaster (listener support in swing slang) is a place 
where you want to mix streams and swing actions.
   listeners.stream().filter(l -> l instanceof XXXListener).forEach(l -> 
l.fireEvent(...));

AWT also claims the name Action for something unrelated (desktop default 
behaviours).

BTW, Block should be renamed to DoIter (Do-it-er) in my opinion ...













:)









sorry, could not resist ...

>
> -Doug
>

Rémi