From: danieldasilvaferreira@... Date: 2018-01-08T15:36:16+00:00 Subject: [ruby-core:84724] [Ruby trunk Bug#14336] Create new method String#symbol? and deprecate Symbol class Issue #14336 has been updated by dsferreira (Daniel Ferreira). There is also one important thing here that deserves consideration: We are doing a great effort to improve the performance of strings and everything associated to them. Symbols are not taking advantage of those improvements. If we keep saying that everything is a Symbol except user input we will be constraining ourselves to use less performant code. Correct me if I���m wrong but if I���m not mistaken immutable strings can be more performant then symbols, not to mention the memory consumption. By merging symbols into strings we can focus all our efforts in improving string���s performance leaving symbols out of the equation. I only see positive things here. The transition path that I present will make sure that no code will be broken. ---------------------------------------- Bug #14336: Create new method String#symbol? and deprecate Symbol class https://bugs.ruby-lang.org/issues/14336#change-69444 * Author: dsferreira (Daniel Ferreira) * Status: Open * Priority: Normal * Assignee: * Target version: * ruby -v: * Backport: 2.3: UNKNOWN, 2.4: UNKNOWN, 2.5: UNKNOWN ---------------------------------------- From the discussions on the three previous issues related to the String vs Symbol subject ([5964](https://bugs.ruby-lang.org/issues/5964), [7792](https://bugs.ruby-lang.org/issues/7792), [14277](https://bugs.ruby-lang.org/issues/14277)) there are some conclusions we can assume: * Current String vs Symbol is not the ideal scenario. See: Matz and Koichi comments. * Current philosophy is to use Symbols as identifiers and Strings when strings are needed. * Current situation is that Symbols are being used in many code bases as strings except for strings that really need the String methods. * Current situation is that we are designing APIs to handle both String and Symbol inputs forcing an overhead of API development. I propose the deprecation of `Symbol` class and the introduction of `String#symbol?`. ```ruby foo = :foo foo.class # => String foo.symbol? # => true bar = "bar" bar.class # => String bar.symbol? # => false ``` For backwards compatibility transition path I propose: ```ruby class Symbol def self.===(var) warn ("Warning message regarding deprecated class") if var.class == Symbol true elsif var.class == String && var.symbol? true else false end end end class String def is_a?(klass) case klass when String true when Symbol self.symbol? else false end end end ``` -- https://bugs.ruby-lang.org/ Unsubscribe: