On Fri, Dec 09, 2005 at 07:52:36PM +0900, daz wrote:
> 
> Chad Perrin wrote:
> >
> > I'd be happy with it either way, as long as it's consistent.
> >
> 
> Without space, it's consistent.
> It's not always what we want it to mean, though.
> 
> 
> * I want to see the result, so I prepend "p ":
> 
> #-----------------------------------------------------
> p (0..5).map do |n|
>   10*n
> end
> #=> C:/TEMP/rb284.TMP:1: warning: (...) interpreted as grouped expression
> #  [- Okay, that's what it is.]
> #=> [0, 1, 2, 3, 4, 5]
> #  [- But that's not what I wanted.  The block binds to method #p
> #  - the argument to #p is ((0..5).map) - an Array (in Ruby 1.8.2)
> #-----------------------------------------------------
> 
> * Remove the space after p
> 
> #-----------------------------------------------------
> p(0..5).map do |n|
>   10*n
> end
> #=> 0..5
> #  [Oh, no !]
> #=> C:/TEMP/rb284.TMP:1: undefined method `map' for nil:NilClass (NoMethodError)
> #  [Aargh!]
> #-----------------------------------------------------

There's a problem of understanding there, not of consistency.  When you
butt the parentheses up against a method like that, you're basically
saying that the method's parameters are exactly what's in the
parentheses -- no more and no less.  At least, that's what seems logical
to me.  When you separate it with a space, parentheses make for a great
way to set precedence within the larger statement while still allowing
the whole thing to be your set of method parameters (or, perhaps more
accurately, let the whole thing return your method parameter(s)).

The problem that arises for me isn't that the meaning of an arrangement
of character on the screen is different from another arrangement: it's
that you can have the parentheses flush with the method or not and it
works the same either way, unless it doesn't.  It just seems to me that,
for consistency's sake, what you use as block delimiters shouldn't
affect whether parentheses for method parameters have to be flush with
the method name itself.

I can do just fine with the way it is, but it seems that it shouldn't
require such a convoluted understanding of how the language behaves.
Ruby, in other ways, conforms very well to the "rule of least surprise";
why should that change in this one instance?

Then again, maybe that's just me.

-- 
Chad Perrin [ CCD CopyWrite | http://ccd.apotheon.org ]

unix virus: If you're using a unixlike OS, please forward
this to 20 others and erase your system partition.