From: Stephen Touset Date: 2011-12-01T23:14:51+09:00 Subject: [ruby-core:41432] [ruby-trunk - Feature #5653] "I strongly discourage the use of autoload in any standard libraries" (Re: autoload will be dead) Issue #5653 has been updated by Stephen Touset. =begin After discussion last night with Yehuda, we both agreed that this issue isn't resolved by #2740. Since (({const_missing})) is never called when Ruby resolves a constant like (({Foo::Bar})) to (({Object::Bar})), it cannot be used as a replacement to (({autoload})), which ((*does*)) trigger before the constant lookup is delegated to (({Object})). This is a more common occurrence than you might think. Requiring any gem or outside library that defines a top-level constant named the same as a nested constant you've autoloaded (via (({const_missing}))) in your project will prevent that nested constant from ever being visible. =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