From: marcandre-ruby-core@...
Date: 2020-12-16T20:55:29+00:00
Subject: [ruby-core:101478] [Ruby master Feature#17393]	`Ractor::Moved#inspect`

Issue #17393 has been updated by marcandre (Marc-Andre Lafortune).


Discussed with ko1, who said he is afraid that unfreezing the class might create issues, as implementation is quite special. Possible implementation of `#inspect` for Ruby 3.1

Two things to keep in mind:
- usecase for unfreezing the class would be to implement `#inspect` in pure Ruby for 3.0, for example.
- it is possible to `refine` frozen classes, including `Ractor::Moved`, so freezing that class may not have the desired effect?

----------------------------------------
Feature #17393: `Ractor::Moved#inspect`
https://bugs.ruby-lang.org/issues/17393#change-89256

* Author: marcandre (Marc-Andre Lafortune)
* Status: Open
* Priority: Normal
* Assignee: ko1 (Koichi Sasada)
----------------------------------------
It could be helpful to define `Ractor::Moved#inspect` and output the source location of when the data was moved. If preferred, it could raise an error with this information:

```
x = []
Ractor.new{ receive }.send(x, move: true)
p x # => "Data was moved in `example.rb:4`"
# or
p x # => "Data was moved in `example.rb:4`" (Ractor::MovedError)
```

Also @zverok and myself were wondering if there was a technical reason to freeze `Ractor::Moved`? If not, is it only to "force" people to use refinements (which are allowed on frozen classes)? It's already known that it is in general a bad idea to modify builtin classes, so it's not clear to me that freezing that class is best.



-- 
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>