[ruby-core:101874] [Ruby master Feature#17490] Rename RubyVM::MJIT to RubyVM::JIT

Issue #17490 has been updated by k0kubun (Takashi Kokubun).


Now some discussions seem to be mixed, so let's sort them out:

## RubyVM::
> 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.
>
> 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).
>
> FYI, I filed #17500 regarding RubyVM.
> I think ExperimentalFeatures::JIT would be fine if we accept that issue, and e.g. other Rubies might implement ExperimentalFeatures::JIT.enabled? then, which makes sense to me.

Yes, let's move to #17500. I thought you would not care about whether it's `WhateverMRISpecificName::MJIT` or `WhateverMRISpecificName::JIT` too.

## --jit
> Agreed the flag should be --jit as it is.

:+1:

## MJIT.pause / .resume
> Since users shouldn't use RubyVM::MJIT methods anyway, I think it doesn't matter much what is the constant name for users.

Yeah, when this API was introduced, it was said that "There is no objection (because RubyVM is just for internal features)" https://bugs.ruby-lang.org/issues/14830#note-3. I expected a similar kind of feedback to this ticket and meant to only confirm that here, although it seems to have triggered other discussions.

## Release notes
> 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.

Are you saying, if we write "JIT" in an MRI release note, readers might get confused about whether it's MRI's JIT or TruffleRuby's Graal?

Once we have another tier of JIT in MRI, I'd agree it's useful to mention the name "MJIT" at least in a NEWS like:

```
# JIT
## Lightweight JIT
...

## MJIT
...
```

but a release note is something which is read by many non-Rubyist people who often don't know there has been a JIT since Ruby 2.6 in the first place. Many people thought Ruby 3 newly introduced a JIT, reading the latest release note. Using our original jargon would simply confuse such audiences. I'm personally *okay* with mentioning MJIT in NEWS.md though.

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

* 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/

Unsubscribe: <mailto:[e-mail]?subject=unsubscribe>
<http://lists.ruby-lang.org/cgi-bin/mailman/options/ruby-core>