Skip to content

Instantly share code, notes, and snippets.

@tagomoris
Last active June 10, 2024 21:57
Show Gist options
  • Save tagomoris/4392f1091f658294bd4d473d8ff631cb to your computer and use it in GitHub Desktop.
Save tagomoris/4392f1091f658294bd4d473d8ff631cb to your computer and use it in GitHub Desktop.
"Namespace on read" for Ruby, FAQ

"Namespace on Read" for Ruby, FAQ

(日本語は後の .jp.md を参照してください)

This document is frequently asked questions and answers about "Namespace on read" for Ruby by tagomoris. "Namespace on read" is proposed to Ruby by tagomoris (but not yet accepted), and a talk in RubyKaigi 2024 introduced it.

This FAQ is written by tagomoris. This FAQ explains my own understanding and nothing are fixed for now (May 20, 2024).

Is the name "Namespace" fixed?

No.

I still be positive to rename the name "Namespace" because now it separates not only names, but also class/module definitions (method, constants, class/module instance variables, and many others). But, at the same time, common english words can't be used because it will conflict to existing names in libraries or applications. (Wow, Namespace is a feature to solve such situations!)

Please let me know if you have a great idea about the name of this feature.

When will it be merged into Ruby? Is it included in the next Ruby release?

I have no idea, but I'm still working hard to finish my implementation and to make it ready for merge. Once I finish it, I'll ask Matz whether it's accepted or rejected.

I hear Matz said this, is it true?: "Once it gets merged into Ruby, I think it would become Ruby 4.0"

Yes. I (and many people) heard it at the closing keynote of RubyKaigi 2024.

But, probably, you misunderstood it. (See the item below...)

Will the version of Ruby be 4.0 if tagomoris's patch is merged?

No.

(Matz and I talked to clear this after the keynote):

Package feature (kind of high level API of Namespace) is the key for Ruby 4.0, and the Namespace on read is a kind of low level API. If Namespace on read is merged into Ruby, it'll be an experimental feature at first, and Ruby 4.0 needs the design and implementation of the high level API.

What's the goal of your "Namespace on read" idea? Does it support Ruby on Rails apps?

Yes. My (tagomoris's) middle-term goal is to host a full-featured web applications (e.g., Ruby on Rails applications) in a namespace, and also host multiple applications in multiple namespace on a Ruby process.

My short-term goal is to implement Namespace as an optional/experimental feature and to be merged into Ruby. It will not support Ruby on Rails applications at first (because ActiveSupport::Autload conflicts with Namespace for now, and it can't be resolve on Namespace's side). After the merge, we'll be able to try running various libraris and applications in it.

The long-term goal is to design/implement the Package (high-level) API, but maybe other people will have their own idea, opinion, design and implementation about it. I don't think I'll be only a proposer of it.

Does Namespace replace Refinements?

No. Never.

The purpose/feature/benefit of Refinements are completely different from the Namespace's one. So that Namespace never replace Refinements. (And I love Refinements :D)

What can I do to support Namespace?

Many things! But unfortunately, not for just now. Now I'm working on the bunch of C code and the CRuby internals. It's not so easy to understand related things quickly unless you're long-term CRuby committer.

But once the Namespace on read will be merged into Ruby (I hope it comes true), there are SO MANY THINGS. We need to:

  • check libraries run well in namespace
  • check applications run well in namespace
  • write patches of namespace
  • add many test cases of namespace
  • write patches for libraries (for example, ActiveSupport, Zeitwerk) to not prevent working in namespace

And so many other things should be done. I don't have so many variations of applications, so the support from many people should be the key factor of well-tested namespace.

(Further items will be added here)

TBD

"Namespace on Read" for Ruby, FAQ

(See .en.md file for the document in English)

このドキュメントはtagomorisによる、Ruby向けの"Namespace on read"というものへの「よくある質問と回答」です。"Namespace on read"はtagomorisによりRubyに対して提案されており(まだacceptedにはなっていません)、またRubyKaigi 2024のトークで紹介されました。

このFAQはtagomorisによって書かれました。またtagomorisの現状の理解を記したものであり、すべて、今後実際にどうなるかを保証するものではありません(2024年5月20日現在)。

"Namespace"という名前はもう決まりですか?

いいえ。

自分はまだ、いい名前が他にあれば"Namespace"という名前を変更する気はあります。なぜならこの機能は既に名前のみを分離するものではなく、クラスやモジュール定義(継承関係、メソッド、定数、クラス/モジュールのインスタンス変数などなど)を分離するものだからです。しかし同時に、一般的な英単語は既に存在するライブラリやアプリケーションで使われている名前と衝突する可能性が高いため使えません、難しい。(まさにこの問題を解決するためのNamespaceなのに!)

NamespaceはいつRubyにマージされるの? 次のRubyのリリースに入る?

どうでしょうね、ただし、そうなることを目指して作業をがんばってます。実装とテストが当面の範囲で終われば、そのときにMatzにどうなるか改めて確認をお願いするつもりです。

Matzが「これが入ったらRuby 4.0にしてもいいかなと思っている」って言ったって聞いたけど本当?

本当。自分は(他に多くの人も)これをRubyKaigi 2024の最後のキーノートで聞きました。

ただし、おそらく、「これが入ったら」は誤解されているかもしれません。(次の項目を読んでください)

tagomorisのパッチがマージされたら次のバージョンはRuby 4.0になるの?

いいえ、なりません。

(キーノートの後にMatzと話して確認した内容):

Ruby 4.0になるには、パッケージ的な機能(Namespaceの上の高レベルAPI的なもの)が必要で、Namespace on readはそのための低レベルAPIという位置付け。もしNamespace on readがマージされても、それはまずexperimentalということにして、Ruby 4.0までにさらに高レベルAPIの設計と実装を行う必要がある。

"Namespace on read"はどこまで目指しているんですか? Ruby on Railsアプリケーションも対象?

はい。自分(tagomoris)の中期的な目標は、完全なWebアプリケーション(例えばRuby on Railsアプリケーション)をnamespaceの中で動かすこと、また1プロセスで、複数のnamespaceを用いて複数のアプリケーションを動作させることです。

また自分の短期的な目標は、Namespaceをoptionalでexperimentalな機能としてRubyにマージしてもらうことです。この時点では、Ruby on Railsアプリケーションを動作させることはおそらくできないでしょう(これはActiveSupport::AutoloadにNamespaceの機能と衝突する部分があるためで、Namespace側では解決はできないと思います)。マージされたら、様々なライブラリやアプリケーションをNamespaceの中で動作させてみることができるようになります。

長期的にはパッケージ(高レベル)APIを設計/実装したいと思っていますが、これについては様々な人がさまざまなアイデア、意見、設計そして実装を持っていることでしょう。自分だけが提案するとは思っていません。

NamespaceがあればRefinementsはいらなくなる?

絶対にそんなことはありません。

Refinementsの目的・機能・利点はNamespaceのものとは完全に異なります。NamespaceがRefinementsのかわりになることはありません。(個人的にはRefinementsは大好きな機能です。)

Namespaceの手助けをしたいですが、何かできますか?

いっぱいあります! しかし残念なことに、今すぐにはちょっと難しいです。今は大量のCのコードとCRubyの内部のしくみを相手に作業をしています。関連することがらを理解するのは、長年のCRubyコミッタでもないかぎりはすぐには難しいでしょう。

しかし、もしNamespaceがRubyにマージされれば(そうなるよう願っています)、大量にやるべきことがあります:

  • 使っているライブラリがnamespaceの中で動くかどうか試す
  • 書いているアプリケーションがnamespaceの中で動くかどうか試す
  • 動かなければ、Namespaceにパッチを書く
  • 動かなかったことについて、Namespaceにテストケースを追加する
  • Namespaceとうまく動かせないライブラリ(たとえばActiveSupportやZeitwerk)に、動作がおかしくならないようパッチを書く

この他にもいっぱいあるでしょう。自分の手元にはそんなにいろんなアプリケーションはないので、Namespaceがちゃんとテストされるかどうかは、より多くの人々に助けてもらえるかどうかにかかっています。

(まだあったら追記する)

TBD

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment