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

[Sam Pullara]

After I finished the survey, I thought of:

Supplier/Processor

Kind of like Procedure but I think more targeted at something that takes something and does something with it.

Sam

On Jan 23, 2013, at 7:08 PM, Zakharov, Vladimir wrote:

> A couple of comments on the survey: 
> 
> Can we have options that we can rank in preference order in the survey? 
> 
> I think it is ok for the survey to include things deemed "objectionable" (by whom?), if they truly are people just won't vote for them.  BTW, I also thought Procedure got quite a few mentions.  
> 
> Thank you,
> Vlad
> 
> The Goldman Sachs Group, Inc. All rights reserved.
> See http://www.gs.com/disclaimer/global_email for important risk disclosures, conflicts of interest and other terms and conditions relating to this e-mail and your reliance on information contained in it.  This message may contain confidential or privileged information.  If you are not the intended recipient, please advise us immediately and delete this message.  See http://www.gs.com/disclaimer/email for further information on confidentiality and the risks of non-secure electronic communication.  If you cannot access these links, please notify us by reply message and we will send the contents to you. 
> 
> 
> -----Original Message-----
> From: lambda-libs-spec-experts-bounces at openjdk.java.net [mailto:lambda-libs-spec-experts-bounces at openjdk.java.net] On Behalf Of Brian Goetz
> Sent: Wednesday, January 23, 2013 4:11 PM
> To: Kevin Bourrillion
> Cc: lambda-libs-spec-experts at openjdk.java.net
> Subject: Re: Let's please rename Block to Receiver before it's too late
> 
> 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>