From: shevegen@... Date: 2017-10-07T04:15:01+00:00 Subject: [ruby-core:83172] [Ruby trunk Feature#7792] Make symbols and strings the same thing Issue #7792 has been updated by shevegen (Robert A. Heiler). I found the old issue here too from the blog article. :) However had, I do not think that frozen strings would be the same (semantic-wise) as Symbols so I am not sure that this would lead to a reconsideration of the String/Symbol distinction. I personally am fine with the way how Symbols behave as-is; I do also understand that other people think of the distinction somewhat annoying - the best example may be HashWithIndifferentAccess :D I mean, that is so long, I wonder how people can use it over "Hash"... but I understand the problem situation. People want to squeeze out whatever is faster - it's like an obsession and somewhat understandable the larger (and perhaps slower) a codebase becomes + amount of users of said codebase. My only minor concern with the distinction was whether I would be able to treat Symbols as String-like for some string-like operations, such as via :foobar[1,2] - but that is already possible. Walks like a duck, quacks like a duck, is a symbolized duck. Actually, an even more radical solution would be to get rid of Symbols altogether, since that would simplify the usage instantly. Are frozen strings and symbols really as fast? I have no benchmarks but I think that symbols may still be faster, since they may do more - but since I have no benchmark, this is just idle speculation. I mention this because the old proposal here wrote "make symbols and strings the same thing" but you could also have a proposal that would "remove symbols" ... :P Matz explained the origin of Symbols back then here: http://blade.nagaokaut.ac.jp/cgi-bin/scat.rb/ruby/ruby-core/52019 I think Symbols became more popular after the Dave-book stating that they are much faster in Hashes than string-object, so since people like speed, they'd use Symbols a lot. I like symbols a lot too, but mostly because ... it's less to type! I can also enable some specific behaviour depending on input arguments given to methods. This may be a very akward usage example but I like it. Perhaps you may have a chance to see the situation be revisited for ruby 3.x but I myself think that the Symbols will stay as they are for other reasons, including inertia. Another factor to be considered is how ruby "views" the its world - and I think that the original idea never was to expose symbols as-is and instead may have users focus only on strings primarily. Btw here is a short discussion at stackoverflow about symbols in lisp: https://stackoverflow.com/questions/8846628/what-exactly-is-a-symbol-in-lisp-scheme What I gather there is that the primary use case is indeed speed (or "light-weight execution") compared to alternatives. ---------------------------------------- Feature #7792: Make symbols and strings the same thing https://bugs.ruby-lang.org/issues/7792#change-67110 * Author: rosenfeld (Rodrigo Rosenfeld Rosas) * Status: Rejected * Priority: Normal * Assignee: matz (Yukihiro Matsumoto) * 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. -- https://bugs.ruby-lang.org/ Unsubscribe: