Issue #5653 has been updated by MSP-Greg (Greg L).


One issue that autoload helps with is stability when the code 'entry point' is not known.  Many applications (eg RubyGems) are largely CLI based, but testing may start anywhere.  Non-typical applications may also use something like RubyGems in a unexpected manner.


With an 'autoload' app, neither the test files nor the application files are burdened with extra require statements due the indeterminate nature of the code 'entry point'.

Issues also appear from parallel testing, conditional requires, running a subset of test files which result in a different set of $LOADED_FEATURES, etc...

----------------------------------------
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-76644

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

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