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

[Joe Bowbeer]

There is already a Processor though it is probably not on the IDE's list of
likely imports:

javax.annotation.processing.Processor

I commented in the small space provided by the survey that I might be OK
with Supplier/Consumer.  (This was an essay question, right?)



On Wed, Jan 23, 2013 at 7:30 PM, Sam Pullara <spullara at gmail.com> wrote:

> 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>
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://mail.openjdk.java.net/pipermail/lambda-libs-spec-experts/attachments/20130123/ae9199c0/attachment-0001.html