[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