Project

General

Profile

Feature #15330

autoload_relative

Added by marcandre (Marc-Andre Lafortune) over 1 year ago. Updated about 2 months ago.

Status:
Open
Priority:
Normal
Target version:
-
[ruby-core:89934]

Description

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.

Also available in: Atom PDF