Thanks all for your valuable input. I think my situation falls into David's category c. And if I understand the difference between 'use' and 'require' here, the former forces the module to be loaded at compile time, while the latter does not. Is that correct?
On Tue, Jun 29, 2010 at 4:21 PM, Eric Wilhelm <enoba...@gmail.com> wrote: > # from David Golden > # on Tuesday 29 June 2010 13:17: > >>>... and each appender can be individually toggled on or off ... >>> ... whether I want the issue detected at compile time or run time I >>> suppose, but is generally frowned upon to put imports down inside >>> class methods? >> >>I tend to think about it like this: >> >>(a) Mandatory for operation? Load it at compile time. >>(b) Optional and almost always loaded in normal operation? Load it at >> compile time. >>(c) Optional and only needed some of the time? Load it at runtime >> if/when needed. > > (d) Significant chunks of code enabled? Package each one separately > with its tests, and compile-time dependencies declared in each dist. > > So, you have an X, which can use the X::screen, X::email, X::foo > plugins / modes / polymorphic functors (or whatever you want to call > them.) Installing X by itself either does "nothing interesting" or > just some very basic functionality beyond loading the PFs, then each > X-foo dist requires X and the 'foo::whatever' modules. > > Then, just `require X::email` whenever needed by the config / usage. > > This will ensure that you've got test coverage on your ::foo. > Otherwise, if 'foo::whatever' happens to get installed after X and > enabled at runtime, you're in a situation where your tests have never > run through that code and the user is going to find any bugs or API > incompatibilities the hard way. > > --Eric > -- > "But as to modern architecture, let us drop it and let us take > modernistic out and shoot it at sunrise." > --F.L. Wright > --------------------------------------------------- > http://scratchcomputing.com > --------------------------------------------------- >
