Forum: Ruby how to use curly brackets vs. 'end' in Ruby

Announcement (2017-05-07): www.ruby-forum.com is now read-only since I unfortunately do not have the time to support and maintain the forum any more. Please see rubyonrails.org/community and ruby-lang.org/en/community for other Rails- und Ruby-related community platforms.
93c3b4dcb27f9727b9b184b30c4f7966?d=identicon&s=25 carlo (Guest)
on 2006-04-28 20:27
i dislike the use of 'end' (just about the only think i *don't* like in
ruby). so, since everybody is saying that this is just a matter of
taste, why won't this work:

class Hello
{
attr_reader :msg
def initialize
{
@msg = "Hello, World"
}
}
h = Hello.new
puts h.msg
print "Press RETURN"
$stdin.gets

Or what about this:

def fib(n)
{
if (n<2)
{
n
}
else
{
fib(n-2)+fib(n-1)
}
}
print(fib(20), "\n");

in other words, i'm more comfortable with {} coming from C,C++, & C# so
what are the precise syntax rules for substituting {} for 'end'? is
there anything wrong with how i structured my code above? I keep getting
syntax errors & "odd number list for Hash" errors, & i'm pretty sure it
has something to do with my syntax, since both of these work in their
original form (using 'end'). obviously, ruby thinks i'm trying to create
a hash. so, how can i use {} instead of 'end' w/o confusing ruby?

Thanks!
31ab75f7ddda241830659630746cdd3a?d=identicon&s=25 Austin Ziegler (Guest)
on 2006-04-28 20:43
(Received via mailing list)
On 4/28/06, carlo <cdicelico@earthlink.net> wrote:
> i dislike the use of 'end' (just about the only think i *don't* like in
> ruby). so, since everybody is saying that this is just a matter of
> taste, why won't this work:

This is not a matter of taste, in the main.

The use of {} signifies the creation of a hash or a block, depending on
context.

What is -- mostly -- a matter of taste is the use of {} vs do/end in
blocks. There is a binding precedence issue.

  task foo { ... } # the block binds to foo, not to task.
  task foo do ... end # the block binds to task, not to foo.

class must be matched with end.
def must be matched with end.
case must be matched with end.
begin must be matched with end.
do must be matched with end.

You're just going to have to get used to end.

-austin
E0d864d9677f3c1482a20152b7cac0e2?d=identicon&s=25 Robert Klemme (Guest)
on 2006-04-28 20:43
(Received via mailing list)
2006/4/28, carlo <cdicelico@earthlink.net>:
> }
> }
> h = Hello.new
> puts h.msg
> print "Press RETURN"
> $stdin.gets

Because it's syntactically not permitted.  Note that {...} can only
replace do...end.

> Or what about this:

same.

> in other words, i'm more comfortable with {} coming from C,C++, & C# so
> what are the precise syntax rules for substituting {} for 'end'? is
> there anything wrong with how i structured my code above? I keep getting
> syntax errors & "odd number list for Hash" errors, & i'm pretty sure it
> has something to do with my syntax, since both of these work in their
> original form (using 'end'). obviously, ruby thinks i'm trying to create
> a hash. so, how can i use {} instead of 'end' w/o confusing ruby?

http://ruby-doc.org/docs/ProgrammingRuby/html/intro.html#S6

Kind regards

robert
49ab3ce5a4922b4747d1d6f330784629?d=identicon&s=25 Jake McArthur (Guest)
on 2006-04-28 20:52
(Received via mailing list)
FYI, the most often used convention is to use {} for single line
blocks and do..end for multiline blocks.

- Jake McArthur
D8fb06dfc08a477ecb0a76ffdbff3475?d=identicon&s=25 Chiaro Scuro (chiaroscuro)
on 2006-04-28 20:55
(Received via mailing list)
If you don't like the 'end'.. well I don't like the 'do' :-)

Not really, it's just that it would be much more readable to have also
'is' and maybe some other keyword to delimit blocks.
31ab75f7ddda241830659630746cdd3a?d=identicon&s=25 Austin Ziegler (Guest)
on 2006-04-28 20:58
(Received via mailing list)
On 4/28/06, Jake McArthur <jake.mcarthur@gmail.com> wrote:
> FYI, the most often used convention is to use {} for single line
> blocks and do..end for multiline blocks.
>
> - Jake McArthur

This is an oft-used convention, but it is probably wrong. I am leaning
more and more toward Jim Weirich's view, where one uses do/end for
blocks that do not return a meaningful value and {} for blocks that do
return a meaningful value, and using parenthesis to ensure binding.

The only exception for this is in DSL environments where I don't want
to expose the idiosyncratic behaviour and therefore tend to encourage
do/end only.

-austin
Bf6862e2a409078e13a3979c00bba1d6?d=identicon&s=25 Gregory Seidman (Guest)
on 2006-04-30 15:14
carlo wrote:
} i dislike the use of 'end' (just about the only think i *don't* like
in
} ruby). so, since everybody is saying that this is just a matter of
} taste, why won't this work:
[...]
} in other words, i'm more comfortable with {} coming from C,C++, & C#
so
} what are the precise syntax rules for substituting {} for 'end'? is
} there anything wrong with how i structured my code above? I keep
getting
} syntax errors & "odd number list for Hash" errors, & i'm pretty sure
it
} has something to do with my syntax, since both of these work in their
} original form (using 'end'). obviously, ruby thinks i'm trying to
create
} a hash. so, how can i use {} instead of 'end' w/o confusing ruby?

In general, the answers you've been getting are along the lines of "you
can't do that" or "that isn't the Ruby way" and, strictly speaking, both
are accurate. That said, there's sort of a way to do it for methods, at
least:

class << Object
  alias defm define_method
end

class Foo
  defm(:bar) { |baz|
    puts baz
  }
end

x = Foo.new
x.bar('Whee!')

So, yeah, it isn't perfect, but if you *really* want that C syntax feel,
that's about as close as you're going to get.

> Thanks!
--Greg
E0d864d9677f3c1482a20152b7cac0e2?d=identicon&s=25 Robert Klemme (Guest)
on 2006-05-03 18:56
(Received via mailing list)
2006/4/28, Austin Ziegler <halostatue@gmail.com>:
> On 4/28/06, Jake McArthur <jake.mcarthur@gmail.com> wrote:
> > FYI, the most often used convention is to use {} for single line
> > blocks and do..end for multiline blocks.
>
> This is an oft-used convention, but it is probably wrong.

I wonder how a convention can be wrong. This may sound like linguistic
nitpicking, but the whole point of a convention seems to be that it's
adhered to. It just "is" but can't be right or wrong IMHO. There might
be more and less usable and easier and more complicate conventions -
but right or wrong?

Kind regards

robert
Bbc4b3fca1ae3161257a8636145b424d?d=identicon&s=25 Elliot Temple (Guest)
on 2006-05-03 18:56
(Received via mailing list)
On Apr 30, 2006, at 8:21 AM, Robert Klemme wrote:

> be more and less usable and easier and more complicate conventions -
> but right or wrong?

How about Sati

http://en.wikipedia.org/wiki/Sati_(practice)

Or stoning adulterers to death.

-- Elliot Temple
http://www.curi.us/blog/
E34b5cae57e0dd170114dba444e37852?d=identicon&s=25 Logan Capaldo (Guest)
on 2006-05-03 18:56
(Received via mailing list)
On Apr 30, 2006, at 2:26 PM, Elliot Temple wrote:

>
> How about Sati
>
> http://en.wikipedia.org/wiki/Sati_(practice)
>
> Or stoning adulterers to death.

Whoa. How about we all pretend their was an implicit "coding" in
front of the word "convention" for the last couple of posts? I think
Mr. Klemme was wondering how a coding convention can be wrong.
4feed660d3728526797edeb4f0467384?d=identicon&s=25 Bill Kelly (Guest)
on 2006-05-03 18:56
(Received via mailing list)
From: "Robert Klemme" <shortcutter@googlemail.com>
> adhered to. It just "is" but can't be right or wrong IMHO. There might
> be more and less usable and easier and more complicate conventions -
> but right or wrong?

You know Robert, I was in complete agreement with you - until
I remembered Hungarian Notation.   <grin>


lpszRegards,

Bill
D8fb06dfc08a477ecb0a76ffdbff3475?d=identicon&s=25 Chiaro Scuro (chiaroscuro)
on 2006-05-03 18:56
(Received via mailing list)
ah! but not may know that there are both bad-hungarian and
good-hungarian !
Bbc4b3fca1ae3161257a8636145b424d?d=identicon&s=25 Elliot Temple (Guest)
on 2006-05-03 18:56
(Received via mailing list)
On Apr 30, 2006, at 11:39 AM, Logan Capaldo wrote:

>>> might
> front of the word "convention" for the last couple of posts? I
> think Mr. Klemme was wondering how a coding convention can be wrong.

How can a (coding) convention be *wrong*, instead of just less
useful, less practical?

The same argument applies to other conventions. Why is Sati *wrong*,
instead of just a less useful, less pleasant way to live?

Ideas have broad consequences that can't be arbitrarily restricted:
they reach out to other fields. The full answer to the Sati case
should include whether anything is wrong at all, and whether
practical considerations have moral consequences. Those issues are
important to the question about coding.

We can even take a dialog about Sati, and then use some of the ideas
to argue about coding. Most of them will work just as well about
either topic.

Jim: "Sure, Sati sounds horrible to us, but they are accustomed to
it, and would be unhappy to live another way. It has practical
consequences, like reducing how many women are available to knit, but
wealth is only a convenience."
Chloe: "Medical textbooks are a kind of wealth, and medicine matters.
With less knitting, they won't be able to buy as high quality medical
books."

So, back to coding. This medical textbook argument will work great.
Some programmers write tools for doing page layouts, and for making
diagrams. Those tools help us make better medical textbooks. The more
convenient and practical the coding conventions of the programmers,
the sooner we will have higher quality medical textbooks.

The idea that medical textbook production is a *practical* issue with
*moral* consequences can be transplanted just fine between the two
cases: it has reach.

This isn't conclusive, of course. Maybe you don't see the moral value
in medicine. But I think it's getting somewhere, to tie those things
together. Most of us are probably persuaded by now. And if we were to
continue on, about Sati, or coding conventions, we'd continue on in
exactly the same way -- discussing medicine -- because it's all tied
to the same issue now.

-- Elliot Temple
http://www.curi.us/blog/
1fba4539b6cafe2e60a2916fa184fc2f?d=identicon&s=25 unknown (Guest)
on 2006-05-03 18:56
(Received via mailing list)
Hi --

On Sat, 29 Apr 2006, carlo wrote:

> i dislike the use of 'end' (just about the only think i *don't* like in
> ruby). so, since everybody is saying that this is just a matter of
> taste, why won't this work:
>
> class Hello
> {
> attr_reader :msg

The point is that the {}/do/end distinction is largely (not entirely)
a matter of taste, not that you can put curly braces anywhere in Ruby
code :-)

> Or what about this:
> }
> }
> print(fib(20), "\n");

Don't forget puts :-)

   puts fib(2)

> in other words, i'm more comfortable with {} coming from C,C++, & C#
> so

I've always found it's much easier, when you're writing Ruby code, to
"come from" Ruby.  That way, you don't have to fight the language, or
convince yourself to be disappointed because it doesn't have the same
syntax as other languages.  You free yourself to enjoy it a lot more.

Also, remember that Ruby is a language, not a vague, unformulated idea
for a language.  It's not Ruby's responsibility to pepper the code
with curly braces because they appear a lot in C, any more than it is
C's responsibility to stop using them because they appear less in
Ruby.


David

--
David A. Black (dblack@wobblini.net)
Ruby Power and Light, LLC (http://www.rubypowerandlight.com)

"Ruby for Rails" PDF now on sale!  http://www.manning.com/black
Paper version coming in early May!
08e4fd192c00c7136ca2ee38105213f7?d=identicon&s=25 Stuart Stegall (Guest)
on 2006-05-03 18:56
(Received via mailing list)
So Hungarian Notation = Bad, Hungarian Women = Good.  Did I get that
right?
D8fb06dfc08a477ecb0a76ffdbff3475?d=identicon&s=25 Chiaro Scuro (chiaroscuro)
on 2006-05-03 18:56
(Received via mailing list)
I certainly cannot disagree with that!

:-)

bad-hungarian is when you prefix a variable name with type information
eg:

  fWidth = fSize

the 'f' simply means float.  you can see you have type compatibilty on
both
sides, but it doesn't say anything about semantic compatibility. fWidth
could be used as a measure in metres, whereas fSize is expressed in
feet!

good-hungarian is when you prefix a variable name with semantic
information

   metric_width = feet_size

you can see immediately that there is a problem there.  both variables
are
of the same type (Float), yet they have a different meaning.

I would argue that in ruby -using duck typing- we use good hungarian
quite a
lot.
A9b6a93b860020caf9d2d1d58c32478f?d=identicon&s=25 Ross Bamford (Guest)
on 2006-05-03 18:56
(Received via mailing list)
On Mon, 2006-05-01 at 06:28 +0900, dblack@wobblini.net wrote:
> I've always found it's much easier, when you're writing Ruby code, to
> "come from" Ruby.  That way, you don't have to fight the language, or
> convince yourself to be disappointed because it doesn't have the same
> syntax as other languages.  You free yourself to enjoy it a lot more.
>

Amen to that.
Cff9eed5d8099e4c2d34eae663aae87e?d=identicon&s=25 Jacob Fugal (Guest)
on 2006-05-03 18:57
(Received via mailing list)
On 4/30/06, chiaro scuro <kiaroskuro@gmail.com> wrote:
>
>    metric_width = feet_size
>
> you can see immediately that there is a problem there.  both variables are
> of the same type (Float), yet they have a different meaning.

This is a good point, but I would hesitate to call that hungarian
notation. If it looked like this:

  mWidth = fSize

Where the m = "metric" and f = "feet", then you could claim hungarian
notation. And if it *did* look like that, I'd campaign in favor of
expanding the prefix. Including "metric_" in the variable name isn't
hungarian notation, it's just a meaningful variable name, and no one
will vote against that.

Jacob Fugal
E0d864d9677f3c1482a20152b7cac0e2?d=identicon&s=25 Robert Klemme (Guest)
on 2006-05-03 18:57
(Received via mailing list)
2006/4/30, Elliot Temple <curi@curi.us>:
> >>> nitpicking, but the whole point of a convention seems to be that
> >> Or stoning adulterers to death.
>
> Jim: "Sure, Sati sounds horrible to us, but they are accustomed to
> convenient and practical the coding conventions of the programmers,
> exactly the same way -- discussing medicine -- because it's all tied
> to the same issue now.

Now, this has become an interesting discussion!  Let's take this a bit
further and maybe put some things into perspective.

Right or wrong can only be decided based on a set of values. We (at
least I assume you're with me here :-)) consider Sati "wrong" because
it contradicts some fundamental value of our society (I won't go into
the discussion of universam human rights...) - that of life itself.

Now, with software we're far more flexible with regard to values to
base a decision on.  For some it's somehow derived from financial
values (i.e. development effort it took to code it in the first place,
cost of maintenance etc.), for some it's more aesthetic (shortness,
symmetry etc.).  I personally view it mostly from the first
perspective and to some degree from the second.  Since *any* coding
convention (i.e. a practice that *most* people of a domain adhere to)
helps in understanding code it's *right* from a financial point of
view.

If you try to replace an existing convention this will incur some cost
- if you achieve it at all.  The cost depends on the number of people
involved and the amount of software that needs to be changed to
implement the new convention (this includes development software like
IDE's etc.). The confusion by a convention change might even cancel
out the effect of a convention at all, i.e., since there are now two
conventions none of them has the power to aid understanding etc. any
more.  Just imagine what would happen in someone would try to replace
the iteration method's name "each" with some other name.

Woa, this has become fairly theoretical. To sum it up: a bad code
convention is better than no code convention.  Or put it another way:
there's a reason why it's so hard to get rid of conventions...

Kind regards

robert
E34b5cae57e0dd170114dba444e37852?d=identicon&s=25 Logan Capaldo (Guest)
on 2006-05-03 18:58
(Received via mailing list)
On Apr 30, 2006, at 5:18 PM, Elliot Temple wrote:
[snip lots of interesting and good stuff]

Sorry, I reacted the way I did, cause I felt that comparison was
_bound_ to cause a horrific flamewar, and I was trying to head it off
before it started. Thankfully, I was mistaken. (Must remember the
average intelligence is higher here than Slashdot ;) )
This topic is locked and can not be replied to.