From: shevegen@... Date: 2018-01-03T09:58:58+00:00 Subject: [ruby-core:84610] [Ruby trunk Feature#14277] Improve strings vs symbols ambiguity Issue #14277 has been updated by shevegen (Robert A. Heiler). > I use the term "Ambiguity" to emphasise the grey area where ruby developers > are using strings and symbols interchangeably without any concerns about > the differences between the two types of objects. This is a general problem. I personally think that ruby would be simpler without ... Symbols. :) But people have been using symbols and symbols were available so I guess matz felt that symbols have a valid use case (speed, performance, lightweight and so forth). I personally like symbols. I use them very happily, most definitely in ways others may not use. Like some_method(:ignore_the_cats) and handling these cases within the method. I also agree with Martin - while it is just a tiny difference, it is easier to write :foo than 'foo'. It may not be of a primary concern, but I like typing less. And I agree as well with as to what Martin wrote that ultimately matz has to decide whether to make a change or not concerning the usage pattern/frequency of symbols. That also dates back to the pickaxe IMO - the old pickaxe wrote that using symbols as keys in a hash is much better aka faster or less memory use. But that was before frozen strings existed by default, so I am not sure if this still applies or not ... lots of knowledge becomes outdates. By the way, I have no problem if alias_method "foo", "bar" would become deprecated. I am not even using alias_method at all in the first place, simply because I don't like it. Just like tenderlove is a puts debugger, and I am a pp debugger, I am an "alias foo bar" person, even though alias and alias_method are not completely the same. I love typing less, usually. :D I think Koichi Sasada referred to the amount of changes required, compared to the amount of real gain, in the symbol-situation. Matz also gave a presentation some time ago about good and bad changes. I have no problem with change if the change makes something better or improves on parts of ruby - speed increases (but I prefer pretty code over min-max speed), did-you-mean gem, omitting require 'pp' and things like that. Some changes are harder ones; encoding is not a real issue to me anymore, but it simply is different compared to the ruby 1.8.x era. Requires me to think more about string1 versus string2 that may have different, thus incompatible, encodings. (The way I work around this in my own projects is by usually specifying the main encoding to be used, in a constant; and then enforcing that in my project. This may be optional if I would use Unicode instead but I rarely do so, for reasons that take too long to explain. My main point here is just the added amount of code that one may have to deal with. Unicode at the least has emojis which I can't resist using; it is also why I keep most of my larger projects flexible. If I want to switch to unicode one day, I should be able to do so easily, by just changing a single constant.) To some of your suggestions: > Use current symbols syntax as yet another strings syntax and stop > using Symbols? As I wrote about above, I would not mind if symbols would not exist in the first place, largely as it may make ruby simpler. So it is not as if I would be completely opposed to your idea. BUT, since I also really like Symbols, or primarily, the syntax it has, I also don't really want to stop using them. If they are treated internally like string objects or string-like objects, I possibly would not mind really, simply because I could keep on using the syntax. But I am also wary of change just for sake of change alone. > Use current symbols syntax as yet another strings syntax and start > use Symbols with a new syntax? This sounds really awful - I hope you don't take it personal but this would probably be the worst of all suggestions. What would be the net gain, just using a new syntax here? Would old code break or require changes? You also did not suggest an alternative syntax to that specifically. What syntax would you propose to then use Symbols? Would :foo still be available or would you remove it? Syntax is also important. When I realized that @@foo is not really needed because @foo works just fine on a "module-level instance" (module Foo; @foo = 42; def self.foo?; @foo etc...) I stopped using @@foo, largely because the syntax was not appealing to me. Unless one wants to use unicode for defining symbols, we do not have that many characters to choose from. > Use current symbols syntax as yet another strings syntax > and use Symbols purely as a class? Similar problem to the above. Anyway, I don't want to discourage you since I understand that this is probably harder to change compared to, say, 10 years ago or so (change takes time too and we did not have frozen strings back then). But to be honest, I do not really see any real net advantage in the proposal alone here. I think this is an area where matz has to decide either way since it is somewhat more difficult, IMO, and only he knows how ruby should be in the end. I also agree that it could only be for ruby 3.x to change. ko1 only gave one use case but I think there are more - in my code I sometimes do "if object.is_a? Symbol" as opposed to whether it is a String. Admittedly the code may be simpler if symbols would not exist in the first place - but since they do, and in your examples symbols would still remain, I'd be hard pressed to really want to have to lose symbols altogether. There also have been some other issue requests where methods were added to Symbols, so I really think that this is a large topic altogether. > As a ruby developer when I use an API I tend to expect that > both strings and symbols are accepted since that has become > the standard way of doing things in ruby land like the > example highlights. That depends on the API. To me it would be weird if an API rejects a symbol input just because it is a symbol, if both strings and symbols exist. Would an API make sense if it distinguishes between 'cat' and :cat alone? It sounds a lot more as an opinionated API aimed for purism rather than practical use. I agree that people may spend time asking these questions (when to use symbols and when to use strings), so I am not against saying to remove symbols altogether IF this would lead to a simpler language (if I could still use :foo) - but if that is not done, then I'd also rather retain the way how ruby uses both. It may not be as elegant or pure as compared to the situation where we'd have no symbols, but I just do not see the net gain really. > When an API doesn't met that expectation things get confusing. It's simple for APIs to handle both symbols and strings. I know that because I am using it in my code. I do, however had, also agree that it would be simpler if ruby hackers would not have to decide between either one. Less brain-power to process. But it's hard to change at this moment in time IMO. So I am somewhat against the proposal, even though I agree with it somewhat. :) > I believe I'm not the only one to have this mind map inferring from > previous discussions. This may well be but you can find opinions on either side of string-versus-symbol discussion. :) > Plus I believe that would kill ruby as a language. People > would go away for good in my opinion because the chaos > would be even worst. This is not a good design goal. People will always tend to use this or that language, for this or that reason. With more choice comes more fragmentation in general. And I very much doubt that the string-versus-symbol debate is why people pick any other language. I also don't think that people often act in a very logical manner - often they make a decision and then just reason to support that decision no matter what. It's how many people "work". ;) (Though that is not to say that they may not have valid reasons for using other languages. Speed issue is one I may tend to agree with IF it is important to someone). There is simply more competition these days IMO. You can also see it in perl; but even PHP has lost grounds in the last ~6 years, largely due to javascript alone IMO. > Now if we accept both syntaxes in the same way and treat them > always as strings we would remove all the extra work we are > having currently to handle the existing differences. This may be one approach but you also wrote above in two of your three examples that the syntax may change or a new syntax may be added; or that symbols may still be available, just with another syntax. So I am confused now. Which variant do we prefer or talk about now? Also note that new syntax for symbols creates new/more complexity as well. Better to not have symbols at all in this case ;) - but as long as they exist, I like the way as it is largely because it has been that way for a really long time. > Wouldn't you be able to use Symbols and the same logic with > solutions 2. or 3. in place? But your solution requires changes there still, right? I am not entirely sure where the real net gain is, unless you refer to the case where there would not be any new syntax for symbols. ---------------------------------------- Feature #14277: Improve strings vs symbols ambiguity https://bugs.ruby-lang.org/issues/14277#change-69155 * Author: dsferreira (Daniel Ferreira) * Status: Open * Priority: Normal * Assignee: * Target version: ---------------------------------------- This is the ambiguity: ```ruby alias_method :foo, :bar alias_method "foo", "bar" ``` Ruby developers are using strings and symbols interchangeably as if they were the same thing. This is happening in ruby core, in ruby gems and in ruby applications. --- This discussion as started 5 years ago in two separate feature requests (both rejected): * [5964](https://bugs.ruby-lang.org/issues/5964) * [7792](https://bugs.ruby-lang.org/issues/7792) I believe ruby will be much better once the ambiguity between strings and symbols is resolved for good and ruby 3.0 is a very good opportunity to do so. From further discussions I got a light of hope that a solution may be accepted if certain conditions are met. Specifically, a clear transition path that could lead the community towards the break of backwards compatibility. In the issue [Make symbols and strings the same thing](https://bugs.ruby-lang.org/issues/7792) ko1 (Koichi Sasada) wrote: > Please consider transition path for users who are using symbol and string difference like: > > key = ... > ... > when key > case String > ... > case Symbol > ... > end > How to find out such programs? > he also wrote: > If you (or someone) find out any good transition path, we think we can consider again. Can we discuss here what are the rules that would allow the transition path solution to be accepted? Also what solutions for the problem are we envisioning? 1. Use current symbols syntax as yet another strings syntax and stop using Symbols? 2. Use current symbols syntax as yet another strings syntax and start use Symbols with a new syntax? 3. Use current symbols syntax as yet another strings syntax and use Symbols purely as a class? From the challenge presented by Koichi I understand that the transition path to be accepted must allow the current code to raise a warning for the situation where the Symbol is not anymore a Symbol but a String. Is this assumption correct? If this is the case then all we need is to make `String::===(foo)` and `Symbol::===(foo)` to raise warnings every time `foo` is a string and it was created using former symbol syntax. This means the `foo` object needs to contain encapsulated the information of the syntax used to define it. Any drawbacks? NOTE: (I'm only considering solutions 2. and 3. for the purpose of this analysis. Meaning Symbol class will still exist.) -- https://bugs.ruby-lang.org/ Unsubscribe: