On Wed, Nov 23, 2011 at 04:34, Luis Lavena <luislavena / gmail.com> wrote:

> On Nov 19, 2011 4:11 AM, "Yukihiro Matsumoto" <matz / ruby-lang.org> wrote:

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

> Thank you for the details matz, hope this means require and $LOADED_FEATURES
> along $LOAD_PATH will get a performance refactoring.
>
> Saying because lazy loading no longer be an option, startup times will
> become a problem in some scenarios.

I second that.  I have mostly switched to using load and
require_relative, as they are the fastest alternative on Windows.
They still do an insane amount of (seemingly) unnecessary work, but at
least they°«re better than require.  I currently still use autoload for
loading bigger features that aren°«t immediately needed at start-up.I
think that this use-case for autoload is still valid and perhaps
should be in the future, in the same way Yehuda mentioned regarding
Rack°«s server adapters.