From: "Eregon (Benoit Daloze) via ruby-core" <ruby-core@...>
Date: 2023-06-08T09:01:56+00:00
Subject: [ruby-core:113816] [Ruby master Feature#19712] IO#reopen removes singleton class

Issue #19712 has been updated by Eregon (Benoit Daloze).


@matz (Yukihiro Matsumoto) wrote in #note-5:
> The `#reopen` has special semantics that re-initialized the IO object. As a result, singleton methods will be wiped out.

Yes, that's the current semantics.
I think it's both confusing and breaking the general guarantee that a Ruby object's class/singleton class (`RBASIC_CLASS(obj)` to be precise) does not change.

I think there is no need for `IO#reopen` to change the class, but we need a migration path.
I think fundamentally `IO#reopen` is a way to change the file descriptor used for that IO, that doesn't need to change the class.
And suppose `STDOUT.reopen(some_Socket)`, it's very unlikely someone would use Socket-specific methods on STDOUT, so I think we also don't need the methods of the argument's class in most cases.
So I think we could change the semantics of `IO#reopen` to not change the class, and I think it would still just work in most cases (and we could adapt the rare cases that do rely on changing the class).


----------------------------------------
Feature #19712: IO#reopen removes singleton class
https://bugs.ruby-lang.org/issues/19712#change-103462

* Author: itarato (Peter Arato)
* Status: Open
* Priority: Normal
----------------------------------------
The documentation states:

> This may dynamically change the actual class of this stream.

As well `#reopen` removes the singleton class, even when the logical class is the same. This can be surprising at times.

An example:

``` ruby
io = File.open(__FILE__)
io.define_singleton_method(:foo) {}
io.reopen(File.open(__FILE__))
io.foo # `<main>': undefined method `foo' for #<File:/test.rb> (NoMethodError)
```

An example where this was an issue: https://github.com/oracle/truffleruby/pull/3088 Tl;dr: a popular gem was enhancing the singleton class of STDOUT, while Rails/ActiveSupport was executing an `IO#reopen` - invalidating the changes by the gem.

While it's hard to trivially solve this with keeping the intended functionality, could it be considered to make edge cases more visible?

Examples:
- `IO#reopen` issues a warning message when the receiver's singleton class has been updated (but keep removing it as of current state)
- `IO#reopen` is limited on instances with a default singleton class, and issues an error when called on an instance with an updated singleton class
- make `IO#reopen` carry over the singleton class *only* if the recipient and argument's class are the same, and yield an error otherwise (different classes)

These are just ideas. I'm more looking for feedback from the core devs at this point. Thanks in advance!



-- 
https://bugs.ruby-lang.org/
 ______________________________________________
 ruby-core mailing list -- ruby-core@ml.ruby-lang.org
 To unsubscribe send an email to ruby-core-leave@ml.ruby-lang.org
 ruby-core info -- https://ml.ruby-lang.org/mailman3/postorius/lists/ruby-core.ml.ruby-lang.org/