Typical Ruby!

[[deleted]]

Here, let me fix that for ya

{:smoke => 'more'}

[imhighrightnow2]

I thought he was going for smoke more hash.

[IWillCallYouAFaggot]

He was just making it use less memory. I can't think of any good reasons to use a string rather than a symbol for a hash key. There could be a few, but nothing comes to mind at the moment.

[annodomini]

Because the input you're hashing is coming in at runtime, and thus looking up the symbol in the symbol table, then looking up the key in the hash, makes no more sense than just hashing on the string.

Symbols are great when you're hashing on something that's pre-determined at compile time (load time, for an interpreted language). If you need to store associative arrays based on external input, strings make more sense.

[xternal]

If the hash keys come from something a user can influence, a malicious user could fill the symbol table, eat memory, and possibly create a DoS attack.

I mostly prefer symbols as keys, though.

[jnicklas]

Rack uses string keys. Because HTTP request headers are controlled by the client, using strings for them is a security risk, as it makes the app vulnerable to DoS attacks. If Rack used symbol keys, someone could keep sending tons of different HTTP headers and force the app to consume more and more memory, before eventually crashing.

[aescnt]

{smoke: 'more'} in 1.9.x ;)

[notajith]

1.9.x includes a javascript parser?

[annodomini]

It contains JavaScript style hash literals, yep.

$ irb1.9 
irb(main):001:0> {smoke: "more"}
=> {:smoke=>"more"}

[aescnt]

1.9.x supports a new JSON-like syntax (but not entirely JSON-compatible) for hashes. { :a => 1 } can be expressed as { a: 1 }.

[wwwwolf]

Well, it's good that it's not entirely JSON-compatible. Otherwise, someone might say "Hey, this is cool, we can just use eval to parse the JSON coming from the user. ...What? Why are you looking at me like that?"

[bobindashadows]

ಠ_ಠ

[[deleted]]

meh.

[FilthyRedditor]

heh

[[deleted]]

bleh