Hash questions

Ruby
1

When I run:

p {“foo” => 1, “bar” => 2, “baz” => 3 }

I get an error.

But when I run:

x = {“foo” => 1, “bar” => 2, “baz” => 3 }
p x

There’s no error.

What’s the difference between the two?

John

2

On Thu, Apr 9, 2009 at 9:18 AM, Hunt J. [email protected] wrote:

There’s no error.

What’s the difference between the two?

John

p( {“foo” => 1, “bar” => 2, “baz” => 3} )

You need parentheses in the first case, I believe, so the that the
parser knows you are not trying to send a block to the method #p.

Todd

3

Hunt J. wrote:

When I run:

p {“foo” => 1, “bar” => 2, “baz” => 3 }

I get an error.

But when I run:

x = {“foo” => 1, “bar” => 2, “baz” => 3 }
p x

There’s no error.

What’s the difference between the two?

John

From what I can tell, ruby is interpreting the beginning of your hash as
the beginning of a block, instead;
p({“foo” => 1, “bar” => 2, “baz” => 3 }) works as intended.

This is seems like a bug to me, although whether it’s a bug with the
parser (finding a block where it should be looking for a hash literal),
a bug with p (asking for a block when it doesn’t use one) or the
documentation (failing to mention that p accepts a block), I’m not sure.

4

On Thu, Apr 9, 2009 at 10:35 AM, Adam G.
[email protected]wrote:

Actually, on a bit more inspection, both puts and print work the same
way, and I imagine there are other methods that do this as well. This
just seems like the parser failing to correctly interpret the ambiguity
of a {.

No, I’d say that the parser is correctly parsing an initial ‘{’ after a
method invocation as a block argument to the invocation.

There’s no need to mention that p, or any other method can be given a
block
since ANY ruby method can be given (and by default) ignore a block.
It’s
just part of the language that you need to learn, like the need to use
self.x = value to invoke an attribute writer method to disambiguate
between
x= as a method and x as a local variable.

–
Rick DeNatale

Blog: http://talklikeaduck.denhaven2.com/
Twitter: http://twitter.com/RickDeNatale
WWR: http://www.workingwithrails.com/person/9021-rick-denatale
LinkedIn: http://www.linkedin.com/in/rickdenatale

5

On 09.04.2009 16:44, Rick DeNatale wrote:

[Note: parts of this message were removed to make it a legal post.]

On Thu, Apr 9, 2009 at 10:35 AM, Adam G. [email protected]wrote:

From what I can tell, ruby is interpreting the beginning of your hash as
the beginning of a block, instead;
p({“foo” => 1, “bar” => 2, “baz” => 3 }) works as intended.

Here’s an alternative

p( “foo” => 1, “bar” => 2, “baz” => 3 )

And no, the observed behavior is not a bug as Rick pointed out.

Cheers

robert

6

From what I can tell, ruby is interpreting the beginning of your hash as
the beginning of a block, instead;
p({“foo” => 1, “bar” => 2, “baz” => 3 }) works as intended.

This is seems like a bug to me, although whether it’s a bug with the
parser (finding a block where it should be looking for a hash literal),
a bug with p (asking for a block when it doesn’t use one) or the
documentation (failing to mention that p accepts a block), I’m not sure.

Actually, on a bit more inspection, both puts and print work the same
way, and I imagine there are other methods that do this as well. This
just seems like the parser failing to correctly interpret the ambiguity
of a {.

7

Robert K. wrote:

p( “foo” => 1, “bar” => 2, “baz” => 3 )

And no, the observed behavior is not a bug as Rick pointed out.

The freedom to skip () parens nearly everywhere comes at a price. You
gotta
think of the space following a method name as a tiny little operator
meaning
“introduce arguments here like a ( would have”.