[ruby-core:101878] [Ruby master Feature#17500] Move RubyVM::* to ExperimentalFeatures

Issue #17500 has been updated by matz (Yukihiro Matsumoto).

Status changed from Open to Rejected

I am not opposed to renaming `RubyVM` module for the reason @eregon stated. But I am strongly against renaming it to `ExperimentalFeatures` or whatever means **experimental**. Users are forced to rewrite their code when the feature becomes out of the experimental phase. It's not good.

In addition, the features under `RubyVM` might be reorganized to CRuby specific ones and ones available on multiple VMs. For example, `RubyVM::MJIT` is certainly CRuby specific. `RubyVM:::AbstractSyntaxTree` might not.

I am OK with renaming `RubyVM` to `CRubyVM` for example. I am not fully satisfied with renaming it to `MRI` for ambiguity.

Matz.


----------------------------------------
Feature #17500: Move RubyVM::* to ExperimentalFeatures
https://bugs.ruby-lang.org/issues/17500#change-89719

* Author: Eregon (Benoit Daloze)
* Status: Rejected
* 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:[e-mail]?subject=unsubscribe>
<http://lists.ruby-lang.org/cgi-bin/mailman/options/ruby-core>