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

[Joe Bowbeer]

I understand your perspective. In my mind, neither Block nor Procedure are
overloaded. Procedure is however by far the more familiar term in this
context, which is why I prefer it.
On Jan 19, 2013 8:47 AM, "Brian Goetz" <brian.goetz at oracle.com> wrote:

> 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
> >
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://mail.openjdk.java.net/pipermail/lambda-libs-spec-experts/attachments/20130119/cedc6d63/attachment.html