ruby-core@ruby-lang.org archive (unofficial mirror)
 help / color / mirror / Atom feed
From: eregontp@gmail.com
To: ruby-core@ruby-lang.org
Subject: [ruby-core:101851] [Ruby master Feature#17490] Rename RubyVM::MJIT to RubyVM::JIT
Date: Fri, 01 Jan 2021 12:20:38 +0000 (UTC)	[thread overview]
Message-ID: <redmine.journal-89683.20210101122038.10073@ruby-lang.org> (raw)
In-Reply-To: redmine.issue-17490.20201230054510.10073@ruby-lang.org

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


k0kubun (Takashi Kokubun) wrote in #note-4:
> Didn't you clarify it by yourself at [Feature #15743]? The person who wrote the line that nobu quoted was you. You made it pretty clear that `RubyVM::MJIT` doesn't need to exist in other implementations.

I tried to document it. I don't think it's good enough, many people don't read class documentation.
If e.g., they see RubyVM::AbstractSyntaxTree in a blog post, they might use it and miss the fact it's MRI-specific, because the name gives no clue about it.
And it gets more complicated, as RubyVM::AbstractSyntaxTree could exist on other Ruby implementations without much issues, while RubyVM::InstructionSequence probably cannot.

> So, would you suggest always explaining what is "M"JIT in every release note 

Actually I think `MJIT` is a lot clearer than `JIT` in e.g. https://www.ruby-lang.org/en/news/2020/12/25/ruby-3-0-0-released/
MJIT is not the only "Ruby Just-in-Time compiler", so being precise seems helpful to me when mentioning it by name.

> and renaming `--jit` to `--mjit` to approach the naming inconsistency issue explained in this ticket? I'm fine with pasting a link for the former, but I'm reluctant to force users to remember the name for the flag.

Agreed the flag should be `--jit` as it is.

Since users shouldn't use RubyVM::MJIT methods anyway, I think it doesn't matter much what is the constant name for users.
My concern is from the name, `RubyVM::JIT` sounds like some official "blessed" API ("the JIT of the Ruby VM", nothing in that name hints it's MRI-specific), while `RubyVM::MJIT` has a hint of "implementation details"/shouldn't be used by casual users.
Really, the fault is the bad name of the `RubyVM` constant which completely misses the most important thing which is to hint it's MRI specific in the name, but I guess that's a lost battle (#15743).

----------------------------------------
Feature #17490: Rename RubyVM::MJIT to RubyVM::JIT
https://bugs.ruby-lang.org/issues/17490#change-89683

* Author: k0kubun (Takashi Kokubun)
* Status: Open
* Priority: Normal
----------------------------------------
## Background
In my understanding, MJIT is a codename like YARV which many people outside Ruby community are not familiar with, so I've used JIT in NEWS or release notes to avoid explaining the "M" part whenever we release a new version. However, because we have the name "MJIT" in one of our constants, we've had some naming inconsistency. For instance, --jit is not --mjit and it's not consistent.

## Proposal
Have the same constant as `RubyVM::JIT`, deprecate `RubyVM::MJIT` from Ruby 3.1, and remove the old one in Ruby 3.2.



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

  parent reply	other threads:[~2021-01-01 12:20 UTC|newest]

Thread overview: 15+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2020-12-30  5:45 [ruby-core:101809] [Ruby master Feature#17490] Rename RubyVM::MJIT to RubyVM::JIT takashikkbn
2020-12-30 15:05 ` [ruby-core:101812] " eregontp
2020-12-30 22:59 ` [ruby-core:101821] " nobu
2020-12-31  7:47 ` [ruby-core:101832] " takashikkbn
2020-12-31  8:05 ` [ruby-core:101833] " hsbt
2021-01-01 12:20 ` eregontp [this message]
2021-01-01 12:48 ` [ruby-core:101853] " eregontp
2021-01-02  3:06 ` [ruby-core:101874] " takashikkbn
2021-01-02 12:50 ` [ruby-core:101879] " eregontp
2021-01-02 15:51 ` [ruby-core:101880] " takashikkbn
2021-01-03 13:28 ` [ruby-core:101886] " eregontp
2021-01-04  4:50 ` [ruby-core:101902] " takashikkbn
2021-01-13  6:29 ` [ruby-core:102051] " matz
2022-01-17  6:00 ` [ruby-core:107154] " znz (Kazuhiro NISHIYAMA)
2022-01-17  6:32 ` [ruby-core:107155] " k0kubun (Takashi Kokubun)

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-89683.20210101122038.10073@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
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).