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

[Brian Goetz]

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.)  

I think this is better than the status quo.  



On Jan 18, 2013, at 10:58 AM, 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

-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://mail.openjdk.java.net/pipermail/lambda-libs-spec-experts/attachments/20130118/f1e7f21c/attachment.html