[ruby-core:56951] [ruby-trunk - Bug #7716] Readdressing Autoload

Issue #7716 has been updated by trans (Thomas Sawyer).


Hmmm.. require and load are never invoked asynchronously?

I am not sure it matters though. Its use is for very specific case. Can it be left to the programmer to ensure thread safety? I don't think the hook can be made thread safe automatically, can it?


----------------------------------------
Bug #7716: Readdressing Autoload
https://bugs.ruby-lang.org/issues/7716#change-41510

Author: trans (Thomas Sawyer)
Status: Feedback
Priority: Normal
Assignee: matz (Yukihiro Matsumoto)
Category: core
Target version: current: 2.1.0
ruby -v: ruby 2.0.0dev (2013-01-18 trunk 38877) [x86_64-linux]
Backport: 


=begin
It has been known for a long time that Autoload does not utilize the normal require method, and thus is unaffected when require is overridden. This makes it impossible to fully implement a custom load system. Obviously, customizing the load system is a fairly rare usecase and thus a low priority. But it can and does occur. The most notable example is RubyGems itself. Without the ability to customize the load system, RubyGems would have been much more difficult, if not impossible, to create. It can be thankful that its particular design does not suffer greatly from the "autoload hole", nonetheless it does have a reported bug b/c of it, #4233. I too have a custom load system that I have been using in a development setting for many years. I use it to simplify vendoring between dependent projects. I would have liked to made public releases of the project, but the autoload issue has always been too much of a show-stopper to make it generally usable.

This issue with autoload has been reported since at least as far back as October 2007. That's over 5 years ago. Over these years, I have asked many times that this issue be addressed and why I needed it addressed. It has been very frustrating to watch this issue languish, year after year, going unresolved. I understand low priority issues, but 5 years!? Finally, just ((*over a year ago*)) Matz declared that "autoload will be dead" in issue #5653. "Well", I thought at the time, "that's one way to fix it". While I still wished autoload would actually be fixed, at least I could rest assured that in due course the problem would dissipate as new releases of projects are made deprecating their use of autoload. 

In the last few days, I have asked a number of notable projects, including Bundler and RubyGems (a standard library mind you!) when we might expect autoload to be removed from their code. After all it's already been over a year since Matz' declaration. But, in all cases, they reported that they had no intentions of removing autoload in the foreseeable future. So much for strong discouragements from our benevolent dictator.

This week I revisited my custom load manager and re-factored the code a great deal. I'm very happy with the new code and think that it's about as good as it's going to get (minor improvements aside). I suppose I can at least be happy that I've had all this time to think about and improve my code. That's good. But at this point I'd would really like to release it all proper-like.

So... since this autoload issue was obviously still not going anywhere, I took it upon myself to fix. Mind you, I am not a C programmer and this is basically right at the limits of my ability to do anything with Ruby's C code. But, I was able to wrangle out how to make a fix and now offer it up here with an enclosed patch. The patch simply adds a Kernel singleton method called #require_autoload which can be overridden to customize it's operation. The patch includes a test to ensure it works. Perhaps there is some preference to handle this differenetly. That's fine, please adjust it as seen fit. But please *do something*! This issue has gone unaddressed long enough. And really, it is only a small bit of code. I ask, and pray, we will see this fix make it into the next release of 2.0 and back-ported tho 1.9. Please.
=end



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