Issue #15592 has been updated by akr (Akira Tanaka).


fxn (Xavier Noria) wrote:
> Zeitwerk has an interface to eager load similar to what it is being suggested, but it is able to do so easily because it controls the autoloads that it sets based solely in the file system.

I guess it needs some convention between constant names and filenames.
I agree it is good if such convention is available.  (convention over configuration)
Unfortunately, Ruby itself has no such reliable convention.

> A generic way to register and eager load as outlined above seems like a chicken and egg problem to me, because you have to evaluate the files in order to execute the autoloads, no? You need to eager load at least a bit to register the autoloads that trigger eager loading.

eager_load_autoloads method would load libraries until no autoload constant:

```
while there are at least one autoload constant
  load one of them (it may add more autoload constants)
end
```

This loop should terminate because there are only finite ruby library files.

Initial list of autoload constants are defined before user application before
eager_load_autoloads.

I think this can be implemented without much problems.


----------------------------------------
Feature #15592: mode where "autoload" behaves like an immediate "require"
https://bugs.ruby-lang.org/issues/15592#change-76761

* Author: akr (Akira Tanaka)
* Status: Open
* Priority: Normal
* Assignee: 
* Target version: 
----------------------------------------
How about a feature to switch "autoload" behavior to "require" immediately.

autoload is a feature for lazy loading.

matz dislikes autoload as [Feature #5653].
I heard that he dislikes class (and other) definitions at arbitrary timing.
I agree that eager loading is safer than lazy loading.

However, lazy loading realize shorter loading time and
it makes development cycle shorter.
It is more important for larger applications as Eregon said in
https://bugs.ruby-lang.org/issues/5653#note-39 .
It is especially important when library loading causes I/O (code generation from DB schema).

These two, safety of eager loading and easier development of lazy loading, conflicts.
But if we can distinguish production mode and development mode,
we can enjoy both benefits.

So, I propose a feature to select autoload behavior from two modes:
- autoload behaves as lazy loading as now in development mode
- autoload behaves as eager loading (immediately invokes "require") in production mode.

There are several idea to switch the mode:

- $AUTOLOAD_MODE = :eager or :lazy
- RubyVM.autoload_mode = :eager or :lazy
- ObjectSpace.autoload_mode = :eager or lazy

I'm not sure there is a good enough one in above list, though.



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

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