[ruby-core:51959] [ruby-trunk - Feature #7792] Make symbols and strings the same thing

["phluid61 (Matthew Kerwin)" <matthew@kerwin.net.au>]

Issue #7792 has been updated by phluid61 (Matthew Kerwin).


rosenfeld (Rodrigo Rosenfeld Rosas) wrote:
> @drbrain, that means I'm unable to do things like
> 
> results << {id: id, name: name}
> 
> and have to use the old syntax all the time (and worrying about the differences all the time):
> 
> results << {'id' => id, 'name' => 'name'}

You say "old syntax," maybe you should think of it as the "general syntax."  Or, as I think of it, the "real syntax."  The new {id: id} syntax is special case sugar for Hashes keyed on Symbols, which we've already determined is not a great thing to be doing in most cases.

> I still believe MRI should try to optimize frozen strings instead of symbols and just make symbols behave like frozen strings. :symbol would be a shortcut to 'symbol'.freeze.
 
But symbols *aren't* strings. You can't do any of the string-specific things on them, except by first casting them to strings.  Why create a string, then use it to generate an (unrelated) type of object? Just create the symbol in the first place (as already happens).
 
> I don't really think any of those micro-benchmarks would justify all the hassle and unhappiness that symbols bring to Ruby programmers.
 
A simple solution presents itself: stop using them.  Or I should say, stop using them except when you absolutely must.

If we stop thinking of them as special/frozen/whatever strings, and stop using them as "strings with construction optimisation," this whole issue becomes irrelevant.  Then we can also stop using the symbol-specific {a: a} syntax, except when it really makes sense.  And voila! everything is gravy.

Earlier you also wrote:
> You can't know in advance if a hash returned by some external code is indexed by string or symbols. You have to test by yourself or check the documentation.

Indeed.  Similarly you can't know in advanced if it's keyed on integers, or CustomMagicClass instances.  Not a symbol-specific issue.  If the library authors cleared up their misconception that symbols are magic strings, you wouldn't have a problem.  Solution: work around their shortcomings, or find/write a better library.
----------------------------------------
Feature #7792: Make symbols and strings the same thing
https://bugs.ruby-lang.org/issues/7792#change-35957

Author: rosenfeld (Rodrigo Rosenfeld Rosas)
Status: Rejected
Priority: Normal
Assignee: matz (Yukihiro Matsumoto)
Category: core
Target version: Next Major


Recently I had to replace several of my symbols to plain strings in my project. Here is what happened:

I generated some results with some class that would add items to an array like this:

results << {id: 1, name: 'abc'}

Then I would store such results in cache using Redis, encoded as a JSON string. But then when I restore the data from cache the hash will be {'id' => 1, 'name' => 'abc'}.

This wasn't a problem until recently because I never used the results directly in the same request before and would always use the value stored on Redis and parsed by JSON.

But recently I had to use the values directly in a view. But then I had a problem because I would have to use symbols in the results for the first time and strings the next times when the result was available on cache. I really don't want to care about memory management in Ruby if possible and symbols forces me to abandon the new sexy hash syntax many times. Now I have to write

results << {'id' => 1, 'name' => 'abc}

when I'd prefer to write

results << {id: 1, name: 'abc}

This is not the first time I had a bad user experience due to symbols being different from strings. And I'm not the only one or ActiveSupport Hash#with_indifferent_access wouldn't be so popular and Rails wouldn't use it all the time internally.

It is really bad when you have to constantly check how you store your keys in your hashes. Am I using symbols or strings as keys? If you use the wrong type on plain hashes you can find a bad time debugging your code. Or you could just use Hash#with_indifferent_access everywhere, thus reducing performance (I guess) and it is pretty inconvenient anyway.

Or if you're comparing the keys of your hash in some "each" closure you have to worry about it being a symbol or a string too.

Ruby is told to be programmers' friendly and it usually is. But symbols are certainly a big exception.


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