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

[Brian Goetz]

Time to close on this.  I've posted an A/B SurveyMonkey survey between 
Source/Sink and Supplier/Block, which seem to be the least objectionable 
combinations.

On 1/18/2013 1:58 PM, 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>