Skip to content

Instantly share code, notes, and snippets.

Last active July 2, 2024 03:01
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

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

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?


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?


(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)


"Namespace on Read" for Ruby, FAQ

(See file for the document in English)

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





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


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

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


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



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の中で動作させてみることができるようになります。






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


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




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