[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: <mailto:[e-mail]?subject=unsubscribe>
<http://lists.ruby-lang.org/cgi-bin/mailman/options/ruby-core>