ruby-core@ruby-lang.org archive (unofficial mirror)
 help / color / Atom feed
From: eregontp@gmail.com
To: ruby-core@ruby-lang.org
Subject: [ruby-core:99436] [Ruby master Feature#15752] A dedicated module for experimental features
Date: Sat, 01 Aug 2020 13:25:53 +0000 (UTC)
Message-ID: <redmine.journal-86891.20200801132553.772@ruby-lang.org> (raw)
In-Reply-To: <redmine.issue-15752.20190407135631.772@ruby-lang.org>

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


The existence of `RubyVM` prevents other Ruby implementations to be fully 100% compatible, because more and more gems start to rely on it.
So either:
* We move most of `RubyVM` to `ExperimentalFeatures` so that other Ruby implementations can implement it for compatibility (e.g., `AbstractSyntaxTree`, `InstructionSequence`).
  That also gives a nice way to experiment with not-yet-stable features/APIs.
* We are fine that other Ruby implementations have a `RubyVM` constant too. That will make it even less clear that `RubyVM` is experimental.

In practice, if CRuby exposes any API, then some gems might rely on it and with enough gems it becomes hard/impossible to remove it.
So if CRuby wants extra API for e.g. internal VM debugging, it should be added only with some special `./configure` flag.
That I think is the only way to prevent gems to (probably unknowingly) depend on CRuby-private APIs that are not meant to be used except for CRuby internal debugging.

----------------------------------------
Feature #15752: A dedicated module for experimental features
https://bugs.ruby-lang.org/issues/15752#change-86891

* Author: Eregon (Benoit Daloze)
* Status: Open
* Priority: Normal
----------------------------------------
I believe we should introduce a module for experimental features portable across Ruby implementations.

An example of such a portable experimental feature is `RubyVM.resolve_feature_path`.
This feature has nothing MRI specific in it, it is a part of basic `require` functionality.
In the future, I would think more experimental features will be introduced, and I think `RubyVM` is not a good place for it.

Currently, `RubyVM` is sometimes used for experimental features, but I believe `RubyVM` should be defined only on MRI and contain only MRI-specific features.
This means it is *impossible* for other implementations such as JRuby and TruffleRuby to define `resolve_feature_path` (even though it's trivial and might be useful for some users),
and keeping `RubyVM` not defined for clearly marking MRI specific features are not available.

This is a problem that will only gets worse as portable experimental features are added to `RubyVM`.
Here is one example of adding an experimental feature but unfortunately there is no common place between Ruby implementations to add it:
https://github.com/jruby/jruby/issues/5206

If other implementations defined `RubyVM`, then only parts of it would be portable and other parts would be MRI specific,
which would be very confusing to both users and Ruby implementers.

Also, `RubyVM` doesn't really indicate by its name that it contains experimental features.

So I propose the obvious name `ExperimentalFeatures`.

I think such a long name is unlikely to clash with existing Object constants, is very clear,
and marks that any usage of it is by definition using not stable APIs that might be removed or changed.

In combination with #15743, this would mean we can very clearly see what kind of feature it is due to explicit naming:

* `ExperimentalFeatures.resolve_feature_path` is a portable experimental feature, which can be supported on other Ruby implementations too.
* `CRuby::InstructionSequence` is a CRuby/MRI-specific feature, which will only be supported on MRI.

OTOH, the `RubyVM` name doesn't indicate this important difference, and doesn't even indicate the features under it might experimental or not portable.

My main motivation here, is allowing other Ruby implementations to support some of these portable experimental features.
There is no reason for only MRI to be able to support code using portable experimental features.

cc @mame @headius



-- 
https://bugs.ruby-lang.org/

       reply index

Thread overview: 6+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
     [not found] <redmine.issue-15752.20190407135631.772@ruby-lang.org>
2020-08-01 13:25 ` eregontp [this message]
2020-08-01 13:29 ` [ruby-core:99438] " eregontp
2020-08-03 19:04 ` [ruby-core:99462] " daniel
2020-08-03 19:34 ` [ruby-core:99463] " eregontp
2020-08-03 19:40 ` [ruby-core:99464] " eregontp
2020-08-04  0:19 ` [ruby-core:99467] " mame

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-list from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

  List information: https://www.ruby-lang.org/en/community/mailing-lists/

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=redmine.journal-86891.20200801132553.772@ruby-lang.org \
    --to=ruby-core@ruby-lang.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link

ruby-core@ruby-lang.org archive (unofficial mirror)

Archives are clonable: git clone --mirror https://public-inbox.org/ruby-core

Example config snippet for mirrors

Newsgroups are available over NNTP:
	nntp://news.public-inbox.org/inbox.comp.lang.ruby.core
	nntp://ou63pmih66umazou.onion/inbox.comp.lang.ruby.core
	nntp://news.gmane.io/gmane.comp.lang.ruby.core

 note: .onion URLs require Tor: https://www.torproject.org/

AGPL code for this site: git clone https://public-inbox.org/public-inbox.git