Let's please rename Block to Receiver before it's too late
    Kevin Bourrillion 
    kevinb at google.com
       
    Fri Jan 18 10:58:52 PST 2013
    
    
  
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
    
    
More information about the lambda-libs-spec-observers
mailing list