Re: DWIM: autoloading classes

[pdcawley]

The problem with deferring loading 'til runtime is that modules that make use of, say CHECK or INIT blocks will fail to work. Admittedly, such modules are usually 'language warping' type tools, but you might be attempting to use them indirectly.

A better option might be to have an Application class that loads everything the app needs in one fell swoop, which also helps with module codependencies. For the purposes of testing, where you want to make sure that modules you believe to be isolated actually are isolated, you could write yourself an export routine, so you could do:

use Application qw/Foo::Bar Foo::Baz Foo::Wibble/;
# Testcode goes here

For evilness points you could have Application detect when it's being run via testing code and have it add any 'new' modules to its list of modules to load when used without a module list. However, I think throwing an exception in all cases would be a rather more sensible option.

Going down that track a little further, if we assume that the only time Application will be used with a module list is during testing (if you want to vary the list of modules for different scripts, subclass Application) then you could have it generate a list of tested modules, then have a 99sanitycheck.t that verifies that Application has been used to explicitly load every module that it will load by default.

Hmm... I think I might have to find the tuits to write this.

[idsfa]

Agreed, run-time loading is a less than ideal solution for any number of modules (it fubars exports, in addition to the already mentioned CHECK and INIT issues). The whole reason that I was even thinking along those lines was because I was looking to avoid having to rewrite code in the main portion of a program every time a new submodule was added to extend the functionality.

This trick is really intended for loading all modules which fullfil a predetermined API, even if they were written long after the application which will use them. Strangely enough, I am actually using perl to write reports (in this case on instances of custom applications) and wanted to stop having to rewrite the damned thing every time we came out with a new product. Now I only have to write code which can gather the desired information from each new app and massage it into the common format.

I'd love to see some way to do this without losing the exports (Win32::TieRegistry's $Registry in particular). Dynamically loading OS-dependant modules would also be nice. Also a million dollars and a pony.

---

Remember, when you stare long into the abyss, you could have been home eating ice cream.