From: shevegen@... Date: 2018-01-08T13:58:06+00:00 Subject: [ruby-core:84714] [Ruby trunk Bug#14336] Create new method String#symbol? and deprecate Symbol class Issue #14336 has been updated by shevegen (Robert A. Heiler). Some comments. > Current String vs Symbol is not the ideal scenario. See: > Matz and Koichi comments. I think both pointed out some problems; koichi pointed out the transition path problem. I think IF there is a decision to remove symbols (just assuming this for the moment), then a transition path should be enabled to start early. Possibly an early deprecation warning; a document on the official ruby homepage too, to encourage ruby hackers to use symbols rather than strings (again, IF it would be decided to do so); and possibly a hybrid situation where both symbols and strings would still work, before eventually removing symbols. Alternatively ruby could also internally treat both the same but I really don't know anything near as much to be able to say something ... useful. What I am just pointing out is that people would need hints about any decision in regards to a change. I guess it could be done in ruby 3.x but it should not be done earlier really. Even then there will be quite a transition cost involved. I am personally still not sure whether this would be worth it (and it's good that I don't have to decide), so I am writing this as a big IF. Matz said a few more things in regards to how symbols originated; and it is also somewhat true that the distinction between symbols and by-default frozen strings, is not a huge one, in my opinion. I mean, a frozen string, that remains the same, should be quite similar to a symbol, that also never changes, yes? Even if the semantics are not completely the same. - One thing that I would like to point out is the syntax issue. I like being able to do: :foobar If I would have to do 'foobar' then I'd have to use one extra character. So I prefer :foobar here. I also actually like Symbols and would rather keep them - HOWEVER had, I also agree (and wrote so myself) that newcomers may be confused about the difference and the different semantics. So it may be easier for newcomers to not have to wonder about when to use what. There are also abominations such as HashWithIndifferentAccess. Now I never used it (it is too long, too verbose and too crazy an idea) but I can understand it. People will say something like "hey, I don't want to have to care between symbols and strings, either way, I just want to have a hash that can deal with this". For that situation, I think it may be easier to just add a method to Hash to allow either key variant; or add an extension class to hash but with a sane name, not this long name. (Or remove symbols, then nobody has to think about the difference; and we'd not see HashWithIndifferentAccess). - IF symbols are removed, then String#symbol? does not make any sense. :) I think it would not be logical to mandate of ruby hackers to query whether a string is a symbol, when symbols ... don't exist anymore. :P > * Current situation is that we are designing APIs to handle both String > and Symbol inputs forcing an overhead of API development. You mention one (possible) drawback - but you don't mention drawbacks in regards to other changes that are required if symbols were removed. Even your example of duck patching class String, it is not the same as the situation BEFORE. Note that I am not at all against removing symbols; and I don't mind to change my code either. But I still don't really see the huge benefit in it for non-newcomers. I have absolutely no problem in dealing with both symbols and strings in any of my ruby code, so there would not be a huge net benefit to me. Even though I am not opposed to getting rid of symbols, to be honest, I'd rather like to keep the current status quo, simply because it does not give me any problem, whereas with the suggestion to change, I'd have to change a lot without a huge net benefit. I don't want to distract from the discussion though, so this is just my personal opinion, and I'll let others comment. At the end of the day, matz has to decide and only he knows how he wants ruby people to use symbols (or not use them; I think matz once said that he was surprised to see how symbols were used e. g. in the rails ecosystem many years ago; I am sure I also misuse symbols, but I like them too). I also just realized that Symbols do not have a .new method. :) ---------------------------------------- Bug #14336: Create new method String#symbol? and deprecate Symbol class https://bugs.ruby-lang.org/issues/14336#change-69434 * 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: