Issue #5653 has been updated by rosenfeld (Rodrigo Rosenfeld Rosas).
Hi Greg, could you please expand on your argument? Testing may start anywhere but tests should require the files they are testing, so I don't understand why autoload could make things more stable. If the tests are failing because of a missing require, including the require will fix the test anyway.
I couldn't get the point regarding CLI based gems. Why would they become more stable by using autoload instead of require?
> Non-typical applications may also use something like RubyGems in an unexpected manner
What are non-typical applications? What does it mean to use something like RubyGems? What would be the unexpected manner? Could you please provide examples?
> With an 'autoload' app, neither the test files nor the application files are burdened with extra require statements"...
Convenience is the only reason I can currently see to use autoload, although I find this to be a subjective reason because not everyone find them convenient.
> ...due the indeterminate nature of the code 'entry point'.
What would be indeterminate in finding the entry point of some CLI or any other Ruby type of code? As long as you type all dependencies in each file relying on them you should be fine no matter what the entry point is. The only reason you might worry about entry points is in case you're worried about fast start-up time and want to apply lazy load to your code.
> Issues also appear from parallel testing, conditional requires, running a subset of test files which result in a different set of $LOADED_FEATURES, etc...
How could those be an issue, could you please provide concrete examples? As long as you always require your dependencies parallel tests should pass as usual. Why are conditional requires a problem without autoload? What is the issue with running a subset of test files? I do that all the time and I don't rely on autoload. What are the issues with having a different set of $LOADED_FEATURES?
----------------------------------------
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-76673
* Author: matz (Yukihiro Matsumoto)
* Status: Assigned
* Priority: Normal
* Assignee: matz (Yukihiro Matsumoto)
* Target version: Next Major
----------------------------------------
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.
---Files--------------------------------
noname (500 Bytes)
5653.pdf (38.3 KB)
--
https://bugs.ruby-lang.org/
Unsubscribe: <mailto:ruby-core-request / ruby-lang.org?subject=unsubscribe>
<http://lists.ruby-lang.org/cgi-bin/mailman/options/ruby-core>