How to use curly brackets vs. 'end' in Ruby

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!

···

--
Posted via http://www.ruby-forum.com/.

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

···

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:

--
Austin Ziegler * halostatue@gmail.com
               * Alternate: austin@halostatue.ca

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

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

···

2006/4/28, carlo <cdicelico@earthlink.net>:

--
Have a look: Robert K. | Flickr

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

···

--
Posted via http://www.ruby-forum.com/\.

Hi --

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 :slight_smile:

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");

Don't forget puts :slight_smile:

   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

···

On Sat, 29 Apr 2006, carlo wrote:

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

"Ruby for Rails" PDF now on sale! Ruby for Rails
Paper version coming in early May!

FYI, the most often used convention is to use {} for single line blocks and do..end for multiline blocks.

- Jake McArthur

···

On Apr 28, 2006, at 1:39 PM, Austin Ziegler wrote:

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

If you don't like the 'end'.. well I don't like the 'do' :slight_smile:

Not really, it's just that it would be much more readable to have also
'is' and maybe some other keyword to delimit blocks.

···

On 4/28/06, Robert Klemme <shortcutter@googlemail.com> wrote:

2006/4/28, carlo <cdicelico@earthlink.net>:
> 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

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?

Programming Ruby: The Pragmatic Programmer's Guide

Kind regards

robert

--
Have a look: Robert K. | Flickr

--
Chiaroscuro
---
Liquid Development: http://liquiddevelopment.blogspot.com/

Amen to that.

···

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.

--
Ross Bamford - rosco@roscopeco.REMOVE.co.uk

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

···

On 4/28/06, Jake McArthur <jake.mcarthur@gmail.com> wrote:

On Apr 28, 2006, at 1:39 PM, Austin Ziegler wrote:

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

--
Austin Ziegler * halostatue@gmail.com
               * Alternate: austin@halostatue.ca

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

···

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.

--
Have a look: Robert K. | Flickr

How about Sati

Or stoning adulterers to death.

-- Elliot Temple

···

On Apr 30, 2006, at 8:21 AM, Robert Klemme wrote:

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?

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

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

lpszRegards,

Bill

···

From: "Robert Klemme" <shortcutter@googlemail.com>

2006/4/28, Austin Ziegler <halostatue@gmail.com>:
> On 4/28/06, Jake McArthur <jake.mcarthur@gmail.com> wrote:

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.

···

On Apr 30, 2006, at 2:26 PM, Elliot Temple wrote:

How about Sati

Sati (practice) - Wikipedia

Or stoning adulterers to death.

ah! but not may know that there are both bad-hungarian and good-hungarian !

···

On 4/30/06, Bill Kelly <billk@cts.com> wrote:

From: "Robert Klemme" <shortcutter@googlemail.com>
>
> 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?

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

lpszRegards,

Bill

--
Chiaroscuro
---
Liquid Development: http://liquiddevelopment.blogspot.com/

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

···

On Apr 30, 2006, at 11:39 AM, Logan Capaldo wrote:

On Apr 30, 2006, at 2:26 PM, Elliot Temple wrote:

Robert Klemme wrote:

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?

How about Sati

Sati (practice) - Wikipedia

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.

So Hungarian Notation = Bad, Hungarian Women = Good. Did I get that right?
chiaro scuro wrote:

···

ah! but not may know that there are both bad-hungarian and good-hungarian !

On 4/30/06, Bill Kelly <billk@cts.com> wrote:

From: "Robert Klemme" <shortcutter@googlemail.com>
>
> 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?

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

lpszRegards,

Bill

--
Chiaroscuro
---
Liquid Development: http://liquiddevelopment.blogspot.com/

I certainly cannot disagree with that!

:slight_smile:

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.

···

On 5/1/06, Stuart Stegall <stuart@footworkmedia.com> wrote:

So Hungarian Notation = Bad, Hungarian Women = Good. Did I get that
right?
chiaro scuro wrote:
> ah! but not may know that there are both bad-hungarian and
> good-hungarian !
>
> On 4/30/06, Bill Kelly <billk@cts.com> wrote:
>>
>> From: "Robert Klemme" <shortcutter@googlemail.com>
>> >
>> > 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?
>>
>> You know Robert, I was in complete agreement with you - until
>> I remembered Hungarian Notation. <grin>
>>
>> lpszRegards,
>>
>> Bill
>>
>
> --
> Chiaroscuro
> ---
> Liquid Development: http://liquiddevelopment.blogspot.com/
>

--
Chiaroscuro
---
Liquid Development: http://liquiddevelopment.blogspot.com/

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

···

2006/4/30, Elliot Temple <curi@curi.us>:

On Apr 30, 2006, at 11:39 AM, Logan Capaldo wrote:

>
> On Apr 30, 2006, at 2:26 PM, Elliot Temple wrote:
>
>> Robert Klemme wrote:
>>
>>> 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?
>>
>> How about Sati
>>
>> Sati (practice) - Wikipedia
>>
>> 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.

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.

--
Have a look: Robert K. | Flickr

[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 :wink: )

···

On Apr 30, 2006, at 5:18 PM, Elliot Temple wrote:

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

···

On 4/30/06, chiaro scuro <kiaroskuro@gmail.com> wrote:

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.