[ruby-core:113795] [Ruby master Feature#19712] IO#reopen removes singleton class

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


@byroot It's not possible to reuse the singleton class for that example. A singleton class has a given superclass, and that must never change.
But I suppose it might be possible to *copy* the singleton class, although that might be surprising as now 2 classes have that singleton method and they are independent.
It's existing behavior though, as Kernel#clone already does this.

I think these changing-class semantics of `IO#reopen` have no place in Ruby, it's not worth breaking the object model so badly for a single method.

So maybe `IO#reopen` should never change the class.
That would mean probably failing then for e.g. `some_File.reopen(some_Socket)`, but `some_IO.reopen(some_Socket)` could be OK.
STDOUT, STDERR and STDIN are all `IO` initially, so `reopen` would still work on them but they would stay `IO` instances, no matter the argument's class.

Of course it's possible to assign `$stdout/$stderr/$stdin` (or even `STDOUT/STDERR/STDIN` if one wishes), instead of using `IO#reopen`.
So then maybe we could deprecate the whole method. But that's likely more difficult for compatibility.

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

* 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 -- [e-mail]
 To unsubscribe send an email to [e-mail]
 ruby-core info -- https://ml.ruby-lang.org/mailman3/postorius/lists/ruby-core.ml.ruby-lang.org/