[#100689] [Ruby master Feature#17303] Make webrick to bundled gems or remove from stdlib — hsbt@...
Issue #17303 has been reported by hsbt (Hiroshi SHIBATA).
11 messages
2020/11/02
[#100852] [Ruby master Feature#17326] Add Kernel#must! to the standard library — zimmerman.jake@...
Issue #17326 has been reported by jez (Jake Zimmerman).
24 messages
2020/11/14
[#100930] [Ruby master Feature#17333] Enumerable#many? — masafumi.o1988@...
Issue #17333 has been reported by okuramasafumi (Masafumi OKURA).
10 messages
2020/11/18
[#101071] [Ruby master Feature#17342] Hash#fetch_set — hunter_spawn@...
Issue #17342 has been reported by MaxLap (Maxime Lapointe).
26 messages
2020/11/25
[ruby-core:101000] [Ruby master Bug#10845] Subclassing String
From:
merch-redmine@...
Date:
2020-11-21 07:31:43 UTC
List:
ruby-core #101000
Issue #10845 has been updated by jeremyevans0 (Jeremy Evans).
naruse (Yui NARUSE) wrote in #note-16:
> In 2.7 we break large compatibilities, and this tickets breaks Rails again.
> "Rails master already fixes it" doesn't care the problem; we breaks compatibility.
In this case, Ruby's behavior resulted in objects that were not internally consistent. Rails has a fair amount of code just to work around the inconsistency , which they will be able to drop once 3.0 is the minimum version (Rails 7?). See https://github.com/rails/rails/blob/1165401ee962aef0aaf81080e3e7dcab522efa40/activesupport/lib/active_support/core_ext/string/output_safety.rb#L248-L253
I appreciate the importance of backwards compatibility. Almost all of my libraries run on Ruby 1.9 - Ruby 3.0. However, I don't think we should skip fixing problems in core Ruby just because it breaks a small part of Rails, especially if fixing the issue in Rails is simple. We should always weigh the costs and benefits when deciding whether compatibility should be broken. That being said, I respect your opinion, and if this experiment causes too many issues, we can revert.
----------------------------------------
Bug #10845: Subclassing String
https://bugs.ruby-lang.org/issues/10845#change-88668
* Author: sawa (Tsuyoshi Sawada)
* Status: Closed
* Priority: Normal
* Assignee: matz (Yukihiro Matsumoto)
* ruby -v: 2.2
* Backport: 2.0.0: UNKNOWN, 2.1: UNKNOWN, 2.2: UNKNOWN
----------------------------------------
If I make a subclass of `String`, the method `*` returns an instance of that class.
~~~ruby
class MyString < String
end
MyString.new("foo").*(2).class #=> MyString
~~~
This is different from other similar operations like `+` and `%`, which return a `String` instance.
~~~ruby
MyString.new("foo").+("bar").class #=> String
MyString.new("%{foo}").%(foo: "bar").class #=> String
~~~
I don't see clear reason why `*` is to be different from `+` and `%`, and thought that perhaps either the behaviour with `*` is a bug, or the behaviour with `+` and `%` is a bug.
Or, is a reason why they are different?
--
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>