in reply to Re^2: Use of Autoloader in Modern Times
in thread Use of Autoloader in Modern Times
Which is one of the reasons why "load dependency at compile-time" vs "load dependency at run-time" should be decided by the environment (when possible). Modules that define new syntax must be loaded at compile-time. A huge fraction of modules don't need to be loaded at compile-time so it can be very handy to allow the invoker to pick which behavior.
Almost all unit tests should delay loading modules since the process isn't going to live very long and isn't going to use the vast majority of functionality eventually reached by the dependency tree (so no reason to wait for all of the too-early initialization over and over). But you should have at least one unit test that specifies "load all dependencies at compile-time" so that you can very quickly tell if any dependencies are missing, even if you haven't figured out how to exercise every single one of them.
Pre-forking servers should load dependencies at compile-time in the parent but at run-time in the children.
Lots of command-line tools (especially in a corporate software development house) can benefit from loading dependencies at run-time, so that I can do something useful with the frobnitz repository management subsystem from my laptop without having to install all of the PDF, XML, e-mail, GD, and plotting modules despite parts of the frobnitz repository needing to know how to send e-mails with PDF and/or XML attachements, some of which contain bar charts as png files (while also not having to constantly groom the dependency tree to make selected dependencies optional or at run-time to get that benefit).
- tye
|
|---|