[ruby-core:90008] [Ruby trunk Feature#15330] autoload_relative

[eregontp@gmail.com]

Issue #15330 has been updated by Eregon (Benoit Daloze).


matz (Yukihiro Matsumoto) wrote:
> I do not like autoload for its indeterministic nature (#5653).
> It caused issues (#10892, #11384, #12688) and they are hard to solve.
> But autoload is so widely used (especially in Rails), we couldn't have removed it.

It seems all of these 3 bugs are solved nowadays.

#5653 mentions "But autoload itself has fundamental flaw under multi-thread environment.", but does not give an example.
What's the fundamental flaw, and what example fails due to it?

I thought autoload would make no effort to save cases like accessing a constant while the module is being defined,
but it actually appears that MRI handles that case fine, and only makes the constant visible to other threads once it's fully defined.

Autoload is a nightmare implementation-wise (also, is it documented anywhere how it works? The code can't be said to be easily readable).
But, if it must remain for compatibility, then I agree with Marc-André that it should not be a reason to not improve autoload (i.e., I think we should add autoload_relative).

----------------------------------------
Feature #15330: autoload_relative
https://bugs.ruby-lang.org/issues/15330#change-75112

* Author: marcandre (Marc-Andre Lafortune)
* Status: Open
* Priority: Normal
* Assignee: matz (Yukihiro Matsumoto)
* Target version: 2.6
----------------------------------------
I'd like to propose a way to autoload a constant using a relative path.

It could look like:

```
autoload_relative :MyConst, 'models/my_const'
```

My proposal raises two questions:

1) what's the future of `autoload`?

I believe that `autoload` has been there for years, it is used successfully and has no real alternative.

I looked at a sample of 430 top gems (took the 500 top ranked according to Libraries.io, removed those that I failed to process). The number of those gems that appear to use `autoload` at least once is 94 of those (22%).

The number of lines in the code where `autoload` is called can be quite big. The top 5 are:
vagrant: 235
yard: 206
ffaker: 155
aws-sdk: 152
rdoc: 92

This is a minimum bound, as some gems might be using loops, my processing would only detect the one place in the code with `autoload`.

2) are many autoladed paths relative?

My preliminary numbers indicate that of the 94 gems using autoload, at least 75 are autoloading some relative files. That's a lower bound, as my algorithm is pretty crude and will only count the simplest cases as being relative. An example of gem my algorithm does not detect is `yard`, because the author wrote a small method to map the relative paths to global paths (code here: https://github.com/lsegal/yard/blob/master/lib/yard/autoload.rb#L3 )

Of those where my processing detects the relative requires, a vast majority are relative. The average is that 94% of autoloaded files are relative and would benefit from `require_relative`

In summary: I am convinced that `autoload` should remain in Ruby indefinitely. `autoload_relative` would actually be more useful than `autoload`. Even if the future of `autoload` remains uncertain, I would recommend adding `autoload_relative`; if it is ever decided to actually remove `autoload`, removing `autoload_relative` would not really add to the (huge) burden of gem maintainers.



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