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

[Brian Goetz]

Let me explain for the record why I fine Procedure and Action so unacceptable.  (Aside from the Algol-68 flashback of Procedure.)   They focus on the wrong aspect of what the abstraction that implements them IS.  Yes, of course they are implementing a procedure / action; a void-returning thing had better have some side-effect or else it is useless.  But from the perspective of how one of these things interacts with other things in an API, it is focusing on the wrong aspect.  The key aspect is: it is something you can put a value to.  Focus on the value.  

Here's an example which I think is highly typical.  For sake of argument, let's call it ValueAcceptingThingie. 

class Hasher implements ValueAcceptingThingie<T> { 
    int hash;

    void accept(T t) { hash = k*hash + t.hashCode(); }

    int getHash() { return hash; }
}

...

ValueAcceptingThingie h = new Hasher();
for (T t : collection)
    h.accept(t);

If we went with a verby name like Procedure or Action, it feels all wrong: a hasher *is not* an action or a procedure.  But the essence of how these things are used is: "take a value from me", just as supplier is "give me a value."  That's where the focus should be.  

And this is not just about Streams, though I'll admit I have Streams on the brain since that's what I've been working on.  But this shows up in other places too. 

There are lots of words other than Sink that would do the job.  The main problem is that nearly every good word is overloaded.  Producer/Consumer would be fine for Supplier/Block, but they have other connotations.  So do many of the otherwise reasonable candidates.  And ones that are sufficiently specific are just too bulky to use.  (Maybe even clunkier than ObjToVoidFunction.)  

Yes, there are places where the value focus is a little strained, such as forEach().  But even there, I think its something you can get used to quickly.  (I've used the phrase 'foreach the elements into the sink' and no one was ever confused by what I meant.)  This mismatch seems far worse than the action-focused mismatch.  


On Jan 19, 2013, at 5:19 AM, 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); }
> 
> -Doug
>