Re: Dynamic use/require

I always wonder why one would need/wish to load modules dynamically. Are they particularly large and would not fit into memory at the same time?

As they are providing the same method, their input and output must be similar, so why not adding an extra input parameter which can be used as a switch inside the one combined module to differentiate accordingly?

And as you are calling your eval in a while loop, there is good chance that after a few runs through the while loop, you have loaded all your different modules anyhow.

CountZero

A program should be light and agile, its subroutines connected like a string of pearls. The spirit and intent of the program should be retained throughout. There should be neither too little or too much, neither needless loops nor useless variables, neither lack of structure nor overwhelming rigidity." - The Tao of Programming, 4.1 - Geoffrey James

Comment on Re: Dynamic use/require Select or Download Code

Replies are listed 'Best First'.
Re^2: Dynamic use/require by Joost (Canon) on Feb 27, 2008 at 21:54 UTC
I always wonder why one would need/wish to load modules dynamically. Are they particularly large and would not fit into memory at the same time? Some times it can be useful to have a plugin mechanism, where the code calling the modules does not know which modules may be available (since the plugins may be written by third parties). In those instances, you need /some/ kind of mechanism to pass (at least) a package name to the system. Having it load at the same time just makes things more stream-lined. "What should it profit a man, if he should win a flame war, yet lose his cool?"	[reply]
Re^3: Dynamic use/require by CountZero (Bishop) on Feb 28, 2008 at 20:49 UTC
A most valid comment and use of dynamically loading modules, but somehow different from what the OP is trying to implement it seems. Maybe something like Module::Pluggable can be coerced to do what the OP wants. CountZero A program should be light and agile, its subroutines connected like a string of pearls. The spirit and intent of the program should be retained throughout. There should be neither too little or too much, neither needless loops nor useless variables, neither lack of structure nor overwhelming rigidity." - The Tao of Programming, 4.1 - Geoffrey James	[reply]