[ruby-core:91228] [Ruby trunk Feature#5653] "I strongly discourage the use of autoload in any standard libraries" (Re: autoload will be dead)

[fxn@hashref.com]

Issue #5653 has been updated by fxn (Xavier Noria).


Hey! I am the author of Zeitwerk, let me do a quick followup here.

First and foremost, I'd like to be very straightforward saying that if Kernel#autoload is killed tomorrow, that would be fine with me. I'd shutdown Zeitwerk and Rails 6 plans without regrets. The Ruby core team are the stedwards of the language. You know better than anybody else the rationale for your decisions, and if you believe you have to definitely say goodbye to Kernel#autoload I'd profoundly respect it.

Having say that. Why have I worked on Zeitwerk while being well aware of this 7-years old issue? For several reasons: The first one is that being so old means to me this issue is not black/white and perhaps is still open for consideration. Another one is that I wanted to solve some very specific problems for which I don't know another solution today. And a third one is that the existence of something like Zeitwerk, Rails adoption, and the kind of problems that it solves could bring more information or context when pondering the future of Kernel#autoload.

Zeitwerk is motivated specifically by two problems: One problem is Rails autoloading, which cannot reproduce Ruby semantics due to lack of information in const_missing, whereas Kernel#autoload logic is builtin in the interpreter and works perfectly. The other one is brittle requires in non-trivial projects. Both of them are explained in the post and Zeitwerk README.

1) Being able to reload code is handy in web applications development. That is replacing the objects stored in the autoloaded constants, not reopening classes by reevaluating the files.

2) In any non-trivial project, getting the require calls right is difficult, you always forget some and gives load order bugs.

3) If you structure your project in a conventional manner in which file paths match constant paths, the requires don't feel DRY. You are repeating something all the time that could be automated.

4) Being able to work as if all your classes and modules are just available everywhere (as in Rails) is a great user experience. That includes what I call explicit namespaces in which you can use child constants in the body of the parent class or module, something that wouln't even be possible eager loading.

5) Being able to transparently load code on demand in development speeds things up in large code bases.

Now, we have to differentiate the problem from the solution. The points are the problem, the use cases, and a solution based on Kernel#autoload a solution that is possible today. If there were other ways to solve the same problems, that would be also great.

And, finally, let me say it again: Whatever decision the Ruby core team agrees on, I'd respectfully accept without regrets.

----------------------------------------
Feature #5653: "I strongly discourage the use of autoload in any standard libraries" (Re: autoload will be dead)
https://bugs.ruby-lang.org/issues/5653#change-76475

* Author: matz (Yukihiro Matsumoto)
* Status: Assigned
* Priority: Normal
* Assignee: matz (Yukihiro Matsumoto)
* Target version: Next Major
----------------------------------------
Hi,
 
Today, I talked with NaHi about enhancing const_missing to enable
autoload-like feature with nested modules.  But autoload itself has
fundamental flaw under multi-thread environment.  I should have remove
autoload when I added threads to the language (threads came a few
months after autoload).
 
So I hereby declare the future deprecation of autoload.  Ruby will
keep autoload for a while, since 2.0 should keep compatibility to 1.9.
But you don't expect it will survive further future, e.g. 3.0.
 
I strongly discourage the use of autoload in any standard libraries.
 
matz.

---Files--------------------------------
noname (500 Bytes)
5653.pdf (38.3 KB)


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