Do/end vs braces

Ruby
21

On Friday 09 December 2005 03:12 am, Chad P. wrote:

On Fri, Dec 09, 2005 at 05:00:13PM +0900, Logan C. wrote:

Doubtful. Matz. has been trying to move in the opposite direction:
irb(main):003:0> puts (“Hello”, “World”)
(irb):3: warning: don’t put space before argument parentheses
Hello
World
=> nil

I’d be happy with it either way, as long as it’s consistent.

Yes, at least the warning would get me out of the habit ast.

SteveT

Steve L.

[email protected]

22

On Dec 9, 2005, at 10:21 AM, Daniel C. wrote:

In the end doesn’t it all come up to a matter of preference? I
prefer the curly braces, others prefer do…end. In my book its a
matter of versatility of the language. Which in turn is a verry
nice feature, IMHO.

I find the different precedence useful.

If I have a method call written without parens, which is common
in ‘imperative style’ ruby, it is very useful to have the do/block
not bind to the last argument. Such as rake tasks:

task :test do
ruby “test/unittest.rb”
end

23

Joe Van D. wrote:

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.

–
Neil S. - [email protected]

‘A republic, if you can keep it.’ – Benjamin Franklin

24

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

task :test .–.
ruby “test/unittest.rb”
‘–’

:slight_smile: T.

25

On Fri, Dec 09, 2005 at 07:52:36PM +0900, daz wrote:

  • I want to see the result, so I prepend "p ":
    #-----------------------------------------------------

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

26

Ezra Z. [email protected] writes:

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.

27

On Dec 9, 2005, at 6:59 AM, Yohanes S. wrote:

Joe Van D. [email protected] writes:

Generally people save do … end for multiline stuff. Don’t think

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 Z.
Yakima Herald-Republic
WebMaster
http://yakimaherald.com
509-577-7732
[email protected]

[1] eigenclass.org

28

On 12/9/05, Chad P. [email protected] wrote:

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

  1. 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 => prints false, returns true
puts(false) || true # explicit, || => prints false, returns true
puts false or true # implicit, or => prints false, returns true
puts false || true # implicit, || => 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 => prints false, returns true
bar(foo) { ; } # explicit, braces => prints false, returns true
bar foo do ; end # implicit, do/end => prints false, returns true
bar foo { ; } # implicit, braces => 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 F.

29

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

[lots of stuff]

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

. . . and unfortunately largely superficial familiarity with Ruby.

–
Chad P. [ 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.

30

“Trans” [email protected] writes:

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

task :test .–.
ruby “test/unittest.rb”
‘–’

Cuuute. Imagine the possibilities, e.g. vertical XHTML:

/
html
xmlns=“XHTML namespace”
/
/
title
/
What a pervert idea!
/


title
/
/


html
/

You get a nice “overview” by turning your head 270°. :slight_smile: