# 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
---------------------------------------------------
