Generalities first: sure you can, but it may not have the same effect. If the module has an import sub, require does not call it. If the variable is used in a closure, that closure will freeze a default or undef at compile time and never see the change. It's all a matter of how the module is designed.
The MIME::Lite source shows $PARANOID used in the initialization of the file-scoped lexical @Uses at the module's runtime. Paraphrasing:
if (!PARANOID) {
push @Uses, $type;
}
Now subs will look to the symbol table for the value of a package global but, if I understand this correctly, the @Uses array is populated once when the module's runtime happens. @Uses depends only on the value of $PARANOID at that time. Reetting $PARANOID later has no effect, as you observed. This is independent of use vs. require. It could be made possible to do this:package MIME::Lite;
our $PARANOID = 1; # doesn't work
package main;
require MIME:Lite;
but that doesn't work because MIME::Lite assigns $PARANOID its default unconditionally (the ||= operator comes to mind here). A redesign of paranoia and type import is needed to get fully featured runtime switching between paranoid and trustful states. So, yes, your problem does appear to be a bug.
The short version is that you must either edit MIME::Lite to set $PARANOID = 1, or else install the extra modules.
It's a different story for your own subs which need the module. If their dependencies are not satisfied until a second round of compilation within runtime, the optimization stage will have to work with much less information, and many foldings will be lost, much unneeded bytecode carried around.
Why do you want to require a module at runtime? If it's for economy, inside a conditional, it may be a false economy.
After Compline,
Zaxo
| 