Forum: Ruby Hash questions

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.
Hunt J. (Guest)
on 2009-04-09 18:18
(Received via mailing list)
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 B. (Guest)
on 2009-04-09 18:29
(Received via mailing list)
On Thu, Apr 9, 2009 at 9:18 AM, Hunt J. <removed_email_address@domain.invalid> 
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
Adam G. (Guest)
on 2009-04-09 18:33
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.
Adam G. (Guest)
on 2009-04-09 18:35
> 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 D. (Guest)
on 2009-04-09 18:45
(Received via mailing list)
On Thu, Apr 9, 2009 at 10:35 AM, Adam G.
<removed_email_address@domain.invalid>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
Robert K. (Guest)
on 2009-04-09 18:51
(Received via mailing list)
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. <removed_email_address@domain.invalid>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
Phlip (Guest)
on 2009-04-09 18:58
(Received via mailing list)
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 topic is locked and can not be replied to.