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

[Jonathan Finn]

Names like Receiver, Sink etc. sound too passive to me, given that a Block has to actually do something with the parameter: store it, draw it etc.

Handler, Action, Procedure are more active. I'm still gunning for Action because it echoes Function (which is nice), it's active and it's shorter than Procedure. I don't see a big problem with Swing's Action because AWT's List hasn't been a problem.

Jonathan

On 19 Jan 2013, at 02:36, Brian Goetz <brian.goetz at oracle.com> 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.)  
> 
> 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
> 

Jonathan Finn
jfinn at boxoftricks.org