Ruby » Ruby master

Feature #14336

Updated by dsferreira (Daniel Ferreira) over 6 years ago

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 
 ```

Back