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

[shevegen@gmail.com]

Issue #15330 has been updated by shevegen (Robert A. Heiler).


I do not have much to add to autoload_relative as such, although I would like to
mention that, similar to require_relative, the shorter variants are easier to 
write - e. g. "require 'path'" versus "require_relative 'path'"; similar to
autoload versus autoload_require.

However had, more importantly to the issue at hand, I think the functionality
that autoload() offers should be retained. That does not necessarily mean
that the name as such should remain (I am neutral about it; I use autoload
myself but I don't mind either way, whether it is there or not), but the
functionality can be useful. Sometimes in large projects, using a linear
setup e. g. require one project after the other, can take quite some time
to startup. This may normally not be a problem, but I found in one of my 
projects where I make use of a REPL, such as the user starting a shell,
before typing commands, I prefer a fast startup time. I was experimenting
with two approaches: one was via autoload, the other was a strange thought
of using Thread.new to load addons that take time, and check whether 
the code was available or not via e. g. Object.const_defined? and something
like that. This would allow the user to start typing stuff, but not all 
parts of the shell would work instantly; it may take up to 7 seconds or
so before all commands would available from that shell. (If anyone is
wondering why that takes so long, I literally have one admin-like shell
interface that pretty much loads ALL the gems and .rb files that I may
ever need; and I was mostly just experimenting anyway.)

The autoload part of the code was actually quite simple; I sort of defined
all autoloads that this shell would use in a single .rb file and not 
worry about it lateron.

I think Hiroshi Shibata made some suggestion some time ago about extending
require (or the require-family in ruby); I myself also wonder how to 
suggest some more flexible way of requiring files, including perhaps 
autoload-functionality there, rather than autoload() as such; or the
ability to use "identifiers" that are mapped on a per-project basis 
to a .rb file, so that we can use something like a single :symbol to
require files even from outside of a project, rather than rely on a
hardcoded path to .rb files that may change - but I am going off-topic.

I just wanted to mention this. So as summary, I think autoload-functionality
should remain; as to whether the name autoload() should remain or not
is, I think, secondary (to me at the least).

I understand that your suggestion is to extend on the autoload-family
with your suggestion :) - but I am really neutral about it either way,
so I don't mind what happens there. (Actually, for my idea of another
require way, I thought of identifiers via something like 
require_project 'rack|base' or require_project 'rack@base' or something
like that, but I did not like my own API suggestion so I did let this
slide; I still think it would be nice to have a way to require .rb 
files without having to hardcode paths to .rb files).

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

* 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/