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

[Doug Lea]

I've never much liked Block. (Maybe only ex-smalltalkers actually
prefer it?) I hadn't thought about it much lately after we
rejected the obviously  (to me) best choice of "Action" (because
Swing took that name) and second choice Procedure.
Having typed "block" hundreds of times in the past few weeks, I'm
finally getting to the point of not being overly distracted by it
though.

Receiver (with method "receive") seems a little less jarring,
but still a little jarring to me. So I guess I abstain.

BTW, "too late" is already on its way. Because of overload
confusability problems, people (including me in CompletableFuture)
are already propagating the Block method name "accept" one
level out to help prevent usage ambiguities ("thenAccept" vs "thenApply").

-Doug


On 01/18/13 13:58, Kevin Bourrillion wrote:
> When I see methods like
>
>    doSomething(IntBlock intBlock);
>    doSomethingElse(Block<String> stringBlock);
>
> ... I can't even guess what these things mean.  What is a "block of string" or
> an "int block"?  If forced to guess, I'd say "well, this clearly has nothing to
> do with a 'block' in the Java language, but that's my best analogy anyway, and
> blocks have no well-defined inputs or outputs, but that int/string has to get
> involved somehow, so..... if that whole block somehow represents an Int in some
> way it must be that the whole thing /evaluates/ to an Int... except wait,
> there's also IntSupplier.... wtf?"
>
> Procedure has similar problems to maybe half the same degree.
>
> But then consider this:
>
>    doSomething(IntReceiver receiver);
>    doSomethingElse(Receiver<String> receiver);
>
> How much clearer could anything be?  It's an int receiver: it receives ints!
>   Bonus: it has a much clearer relationship to Supplier.
>
> I have scoured the threads to find what the problems are that people had with
> Receiver, and I haven't found any. Privately Brian guessed the problem could be
> "confusion with receiver in the sense of method receiver?"  But that's not even
> a term 95% of normal Java developers know or use.  And even if so, the meaning
> of "an int receiver" is so clear the mind doesn't even /go/ there.
>
> Agree/disagree/neutral?
>
> --
> Kevin Bourrillion | Java Librarian | Google, Inc. |kevinb at google.com
> <mailto:kevinb at google.com>