From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: X-Original-To: poffice@blade.nagaokaut.ac.jp Delivered-To: poffice@blade.nagaokaut.ac.jp Received: from kankan.nagaokaut.ac.jp (kankan.nagaokaut.ac.jp [133.44.2.24]) by blade.nagaokaut.ac.jp (Postfix) with ESMTP id 4927117CEB8A for ; Wed, 3 Apr 2013 19:29:17 +0900 (JST) Received: from funfun.nagaokaut.ac.jp (smtp.nagaokaut.ac.jp [133.44.2.201]) by kankan.nagaokaut.ac.jp (Postfix) with ESMTP id 8E794EA6EEE for ; Wed, 3 Apr 2013 19:06:40 +0900 (JST) Received: from funfun.nagaokaut.ac.jp (localhost.nagaokaut.ac.jp [127.0.0.1]) by funfun.nagaokaut.ac.jp (Postfix) with ESMTP id 94EFF97A82B for ; Wed, 3 Apr 2013 19:06:40 +0900 (JST) X-Virus-Scanned: amavisd-new at nagaokaut.ac.jp Received: from funfun.nagaokaut.ac.jp ([127.0.0.1]) by funfun.nagaokaut.ac.jp (funfun.nagaokaut.ac.jp [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id uFopETXdiTqp for ; Wed, 3 Apr 2013 19:06:40 +0900 (JST) Received: from voscc.nagaokaut.ac.jp (voscc.nagaokaut.ac.jp [133.44.1.100]) by funfun.nagaokaut.ac.jp (Postfix) with ESMTP id 723F697A826 for ; Wed, 3 Apr 2013 19:06:40 +0900 (JST) Received: from carbon.ruby-lang.org (carbon.ruby-lang.org [221.186.184.68]) by voscc.nagaokaut.ac.jp (Postfix) with ESMTP id 03ABC952422 for ; Wed, 3 Apr 2013 19:06:37 +0900 (JST) Received: from beryllium.ruby-lang.org (beryllium.ruby-lang.org [127.0.0.1]) by carbon.ruby-lang.org (Postfix) with ESMTP id D65693C21D3A3; Wed, 3 Apr 2013 19:06:36 +0900 (JST) Received: from fluorine.ruby-lang.org (www.rubyist.net [210.251.121.216]) by carbon.ruby-lang.org (Postfix) with ESMTP id 479D73C21E207 for ; Wed, 3 Apr 2013 19:06:36 +0900 (JST) Received: from ruby-lang.org (localhost [127.0.0.1]) by fluorine.ruby-lang.org (Postfix) with ESMTP id 06A143ED21 for ; Wed, 3 Apr 2013 19:06:36 +0900 (JST) Delivered-To: ruby-core@ruby-lang.org Date: Wed, 3 Apr 2013 19:06:36 +0900 Posted: Wed, 3 Apr 2013 19:06:35 +0900 From: "wardrop (Tom Wardrop)" Reply-To: ruby-core@ruby-lang.org Subject: [ruby-core:53952] [ruby-trunk - Feature #7792] Make symbols and strings the same thing To: ruby-core@ruby-lang.org Message-Id: References: X-ML-Name: ruby-core X-Mail-Count: 53952 X-MLServer: fml [fml 4.0.3 release (20011202/4.0.3)]; post only (only members can post) X-ML-Info: If you have a question, send e-mail with the body "help" (without quotes) to the address ruby-core-ctl@ruby-lang.org; help= X-Mailer: Redmine X-Redmine-Issue-Author: rosenfeld X-Redmine-Issue-Assignee: matz X-Auto-Response-Suppress: OOF X-Redmine-Issue-Id: 7792 X-Redmine-Mailinglistintegration-Message-Ids: 27119 X-Redmine-Project: ruby-trunk Auto-Submitted: auto-generated X-Redmine-Site: Ruby Issue Tracking System X-Redmine-Host: bugs.ruby-lang.org Mime-Version: 1.0 Content-Type: text/plain; charset=utf-8 Precedence: bulk List-Id: ruby-core.ruby-lang.org List-Software: fml [fml 4.0.3 release (20011202/4.0.3)] List-Post: List-Owner: List-Help: List-Unsubscribe: Issue #7792 has been updated by wardrop (Tom Wardrop). =begin = To Summerise... == Symbol Differences === Immutable A symbol is an alias for a numeric ID. The symbol representation of that numeric ID can never change. === Not garbage collected An extension of the previous point. Garbage collecting symbol's would break the fact that symbol's are an alias for a specific numeric ID. === Semantically different The type difference between a String and a Symbol can be used in program logic. == The Problem ((*And yes, there is clearly a problem!*)) === Inconsistance use It's virtually impossible to reliably determine when to use a Symbol or a String. Today, Symbol might be the logical choice for scenario X, but tomorrow you're looking up those Symbols with user-entered data, or reading them in from a file, etc. Programs change, requirements change, everything changes. === Library incompatibility As a consequence of the previous point, combined with different levels of programmer experience and plain personal opinion, libraries will always contain incompatibility. === Unignorable (((*It's a real word, I swear*))) As a consequence of the previous two, even if you only use one or the other, unless you want to avoid using 3rd party code, stdlib, or even ruby-core, there's no way to ignore the fact that Symbol's are different and completely incompatible with String's. Pita. == The Solution Or more to the point, what criteria does a solution need to meet. I don't believe any solution can resolve all the problems, while maintaing full backwards compatibility. Therefore, I see there being a short-term solution, i.e. minor version release of 2.x, and a long term solution, i.e 3.0. I think the Ruby project needs to maintain a list of desired backwards-incompatible changes, so these can be rolled up into one big 3.0 release. Ruby can't be backwards compatible forever, otherwise it'll slowly fade into insignificance... hey Microsoft. === Short Term I don't think there is one. HashWithIndifferentAccess will not solve the problem with hash keys. You'll just go from coercing Symbols to String and vice versa, to coercing Hash to HashWithIndifferentAccess, and back again, and there's no way we can make the differences ignorable to those libraries that don't care, while still satisfying those libraries that do care. Anything we change will probably only help to dig us all a deeper hole. The short term solution is to accept there's a problem, but that there's nothing worth changing without breaking backward-compatibility. === Long Term I propose the remainder of this thread should focus on a long term solution that solves ALL the problems without worrying about full backwards-compatibility, and for everyone to accept that there is indeed a problem with the existence and/or current implementation of Strings and Symbols. Getting rid of Symbols, making Symbols a sub-class of String, whatever. Let's talk about that now, please. =end ---------------------------------------- Feature #7792: Make symbols and strings the same thing https://bugs.ruby-lang.org/issues/7792#change-38165 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/