Issue #4801 has been updated by Eric Hodel.

File bm.rb added

How do you determine (or who determines) "what makes the most sense in terms of memory and the garbage collector"?

For a Hash with keys that are all the same class (String or Symbol) the best performance comes from matching the Hash's keys to the input type's key.  Attached is a benchmark illustrating this, here is the output: http://paste.segment7.net/mu.html

More simply, if you have String input (say from a user, or as parameters from an HTTP request) your Hash should have String keys.  If you have internal fixed values you're looking up you should use Symbols for both.

By using the simple guideline of "make the Hash keys match the key's class" we don't need any changes to Ruby to do what makes the most sense.

PS: This discussion seems to be a bit off-topic from the one in the subject line.

PPS: If you think Ruby should determine "what makes the most sense in terms of memory and the garbage collector" I think you've got a PhD thesis on your hands.
----------------------------------------
Feature #4801: Shorthand Hash Syntax for Strings
http://redmine.ruby-lang.org/issues/4801

Author: Tom Wardrop
Status: Open
Priority: Normal
Assignee: 
Category: 
Target version: 


Assuming there's no technical limitation or ambiguities, I suggest that the shorthand syntax for symbol's in the context of an array, be applied to strings also.

E.g. {'key': 'value'}

I don't believe there are any syntax ambiguous that this would give rise to. The only consideration that may need to be made, is if there are plans to support shorthand syntax for quoted symbols, e.g. {'key': 'value'}. If quoted symbols are off the table, then there's no harm in implementing a shorthand hash syntax for strings. This may stem the growing problem of what I like to call 'symbolitis' , where symbol's are selected as the key type purely for their aesthetics and ease of use, even when strings are a more appropriate choice.

Thoughts?


-- 
http://redmine.ruby-lang.org