[#84867] [Ruby trunk Bug#14357] thread_safe tests suite segfaults — v.ondruch@...

Issue #14357 has been reported by vo.x (Vit Ondruch).

11 messages 2018/01/15

[#84980] [Ruby trunk Feature#13618][Assigned] [PATCH] auto fiber schedule for rb_wait_for_single_fd and rb_waitpid — hsbt@...

Issue #13618 has been updated by hsbt (Hiroshi SHIBATA).

10 messages 2018/01/23
[#85012] Re: [Ruby trunk Feature#13618][Assigned] [PATCH] auto fiber schedule for rb_wait_for_single_fd and rb_waitpid — Eric Wong <normalperson@...> 2018/01/23

hsbt@ruby-lang.org wrote:

[ruby-core:84743] [Ruby trunk Feature#14336] Create new method String#symbol? and deprecate Symbol class

From: danieldasilvaferreira@...
Date: 2018-01-08 22:53:40 UTC
List: ruby-core #84743
Issue #14336 has been updated by dsferreira (Daniel Ferreira).


 matz (Yukihiro Matsumoto) wrote:

>  But it's not wise to change Ruby because of your unfamiliarity.

This subject is really hard to discuss.

In the description I start by mentioning the other three issues already created about the subject.
And I also mention the comments previously made.

If it was just my unfamiliarity I don't think we would have a situation where so many people using ruby use things like `HashWithIndifferentAccess`.
If there is something that I don't like is to use such things.
If I was unfamiliar with ruby I would happily use it as many do.

I refuse myself to do it. But then I have to deal with that.
`HashWithIndifferentAccess` is a very big smell in the language.

This proposal now rejected was an attempt to come up with a transition path to put things in the right place.

Because if ruby community has the need to come up with such things as `HashWithIndifferentAccess` then we have a really big problem.

I still think ruby 3 is an awesome opportunity we will have to resolve such matter.
And I'm still committed to help on that.

Many Thanks

----------------------------------------
Feature #14336: Create new method String#symbol? and deprecate Symbol class
https://bugs.ruby-lang.org/issues/14336#change-69463

* Author: dsferreira (Daniel Ferreira)
* Status: Rejected
* Priority: Normal
* Assignee: 
* Target version: 
----------------------------------------
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:ruby-core-request@ruby-lang.org?subject=unsubscribe>
<http://lists.ruby-lang.org/cgi-bin/mailman/options/ruby-core>

In This Thread

Prev Next