[ruby-core:101855] [Ruby master Feature#17500] Move RubyVM::* to ExperimentalFeatures
From:
eregontp@...
Date:
2021-01-01 12:56:21 UTC
List:
ruby-core #101855
Issue #17500 has been updated by Eregon (Benoit Daloze). Migration plan: * In Ruby 3.1: define `ExperimentalFeatures`, add the same constants & methods as `RubyVM` under it, and deprecate the `RubyVM` constant. User code can do `ExperimentalFeatures = RubyVM unless defined?(ExperimentalFeatures)` to work seemlessly with Ruby<=3.0 and Ruby>=3.1. * In Ruby 3.2: remove the `RubyVM` constant. ---------------------------------------- Feature #17500: Move RubyVM::* to ExperimentalFeatures https://bugs.ruby-lang.org/issues/17500#change-89692 * Author: Eregon (Benoit Daloze) * Status: Open * Priority: Normal * Target version: 3.1 ---------------------------------------- `RubyVM` is a trap: * Users will think from the name it's some official blessed API when it is meant as experimental unstable MRI-specific APIs (the complete opposite). * CRuby developers seem to see it as an experimental module to put constants and methods which are not stable yet. * About half the things under RubyVM is MRI-specific and the other half not, which is confusing and problematic for other Ruby implementations. I think the best way to solve this is to move everything under RubyVM to `ExperimentalFeatures`, and deprecate `RubyVM`. That achieves multiple important things: * it makes it clear such constants/methods are experimental (documentation is not enough, https://bugs.ruby-lang.org/issues/17490#note-6) * it makes it possible for other Ruby implementations to implement such API, if it makes sense for compatibility * it avoids the common pitfall of CRuby developers thinking an API is MRI-specific when in fact it's not, and such an API often end up being used in gems and so other Ruby implementations must implement it for compatibility. In my opinion, keeping the current status quo is irresponsible for compatibility between Rubies. Users end up using e.g. RubyVM::AbstractSyntaxTree in gems (often missing the fact it's experimental), which is something other Rubies can technically implement, but currently are prevented to since `RubyVM` is supposed to be MRI-specific. That's just one example, I think more than half of what has been under RubyVM is not MRI-specific. So rather than guessing if some new experimental API is implementation-specific, let's add all new experimental APIs under `ExperimentalFeatures`. I believe this is better for everyone. It means there is no module for MRI-specific features. That's on purpose, every method in MRI is eventually relied upon by some gem or program, so it should be in `ExperimentalFeatures` if experimental and somewhere as a normal API otherwise. -- https://bugs.ruby-lang.org/ Unsubscribe: <mailto:[email protected]?subject=unsubscribe> <http://lists.ruby-lang.org/cgi-bin/mailman/options/ruby-core>