Hash questions

[Hunt Jon]

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

 

[Todd Benson]

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

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

 

[Adam Gardner]

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.

 

[Adam Gardner]

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

 

[Rick DeNatale]

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

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

 

[Robert Klemme]

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

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

 

[Phlip]

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