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

[Sam Pullara]

Seems reasonable to me. Other options:

Handler
Taker
Consumer

I only offer them up because Receiver sounds likes events or message passing to me.

Sam

On Jan 18, 2013, at 10:58 AM, Kevin Bourrillion <kevinb at google.com> 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