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: