Issue #5653 has been updated by Stephen Touset.


=begin
@ThomasSawyer That kind of approach falls apart when you have multiple entry points into your library that require various features.

I've long considered it (perhaps incorrectly) a best practice to organize my hierarchy as this gist:

    https://gist.github.com/1412552

It has several advantages. Users can require everything in my library with only using the top-level file ((({require 'foo'}))), but without incurring an immediate performance penalty for loading the entire library. It becomes loaded progressively as modules are needed, and only needed modules are ever loaded. It also allows a user to require only a nested component of my library ((({require 'foo/baz/qux'}))) and have everything above it automatically pulled in; again, without pre-loading unnecessary parts of the library.

Of course, the disadvantage is that (({autoload})) is being removed. So what alternative exists that lets library authors be considerate to their users, while still ensuring thread-safety?
=end

----------------------------------------
Feature #5653: "I strongly discourage the use of autoload in any standard libraries" (Re: autoload will be dead)
http://redmine.ruby-lang.org/issues/5653

Author: Yukihiro Matsumoto
Status: Open
Priority: Normal
Assignee: 
Category: lib
Target version: 2.0.0


 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.


-- 
http://redmine.ruby-lang.org