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
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
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
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 xThere’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.
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
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
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 {.
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”.
This forum is not affiliated to the Ruby language, Ruby on Rails framework, nor any Ruby applications discussed here.
Sponsor our Newsletter | Privacy Policy | Terms of Service | Remote Ruby Jobs