do/end vs braces

[Trans]

I've sometimes thought, "man wouldn't it be tight if we had some sort
of vertical brackets?"

task :test .--.
ruby "test/unittest.rb"
'--'

T.

 

[Neil Stevens]

Generally people save do .. end for multiline stuff. Don't think
there's a difference in speed.

I use do .. end always. I find it easier to read, and more in line with
the other foo .. end structures in ruby.

 

[Ezra Zygmuntowicz]

Yohanes-

I have been using this link[1] for converting between do .. end and
{..} in vim and it works great. Thought I would share.


Cheers-
-Ezra Zygmuntowicz
Yakima Herald-Republic
WebMaster
http://yakimaherald.com
509-577-7732
(e-mail address removed)


[1] http://eigenclass.org/hiki.rb?Ruby+block+conversion+macros+for+Vim

 

[Chad Perrin]

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.

 

[Yohanes Santoso]

Yohanes-

I have been using this link[1] for converting between do
.. end and {..} in vim and it works great. Thought I would share.

Thank you for the thought, although I can't use that as I'm using
emacs, not vim. I also have a similar function that does that in
emacs, but that's beside my point.

My point is, that Pickaxe is recommending a convention that compels
the programmer to do something when the LOC changes, unexpected.

They could have recommended a convention that is not based on LOC.

YS.

 

[Jacob Fugal]

... 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.

1) Choice of block delimiters has no more influence on whether
parentheses for method parameters have to be flush with the method
name itself than choosing 'and' vs. '&&' does... and that is none.

In my ruby (1.8.2, 2005-04-11, i386-linux) I don't even get the
warning about not putting spaces in. As far as I can tell, putting a
space between the method and the open parenthesis is equivalent to not
parenthesizing your argument list; the parentheses that had been an
argument list marker are now only a precedence operation. On that
assumption, the warning is either newer or older, and only serves to
chastise (ie. *warn*) those that are making the mistake of thinking
their parens are marking the parameter list when they really aren't.

2) With regards to implicit method parameters, the effect of choosing
do/end over braces is no different than the choice of 'and' over '&&'
-- or 'or' over '||'. Example:

puts(false) or true # explicit, or =3D> prints false, returns true
puts(false) || true # explicit, || =3D> prints false, returns true
puts false or true # implicit, or =3D> prints false, returns true
puts false || true # implicit, || =3D> prints true, returns nil

Both explicit method calls know their arguments exactly. The implicit
method calls, however, get different argument lists depending on the
*precedence*. The || operator binds higher than the implicit method
call, but the 'or' operator does not.

Similarly, the {} block syntax binds higher than the implicit method
call. The 'do ... end' block syntax does not:

def foo
block_given?
end

def bar( arg )
puts arg
block_given?
end

bar(foo) do ; end # explicit, do/end =3D> prints false, returns true
bar(foo) { ; } # explicit, braces =3D> prints false, returns true
bar foo do ; end # implicit, do/end =3D> prints false, returns true
bar foo { ; } # implicit, braces =3D> prints true, returns false

That's it. That's the difference between do/end and braces. Period.
Any other difference is only convention and personal preference.

Jacob Fugal

 

[Chad Perrin]

On Sat, Dec 10, 2005 at 06:14:21AM +0900, Jacob Fugal wrote:

[lots of stuff]

Thanks for the clarification. I blame my momentary lapse on lack of
sleep.

. . and unfortunately largely superficial familiarity with Ruby.