Issue #5653 has been updated by mame (Yusuke Endoh).

Status changed from Open to Assigned
Assignee set to nahi (Hiroshi Nakamura)

Hello, NaHi-san

Hiroshi Nakamura wrote:
> This ticket is for discussion about removing autoload from stdlib (or not)


It would be good to open tickets for each library that uses autoload.

And, what do you think about Stephen and Yehuda's opinion?
It looks reasonable to me.


Stephen Touset wrote:
> 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.

-- 
Yusuke Endoh <mame / tsg.ne.jp>
----------------------------------------
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-25265

Author: matz (Yukihiro Matsumoto)
Status: Assigned
Priority: Normal
Assignee: nahi (Hiroshi Nakamura)
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://bugs.ruby-lang.org/