Re^2: OO factory behind simple methods

Interesting, thanks for the references; I was familiar with neither, and they both look to aid in such design. Module::Load may well do what I need; Module::Pluggable seems more flexible, although a bit overkill for this project, but it may serve well in future endeavors.

Thanks for the information; I've included some additional findings I've made from playing with this module, and follow-up comments. ~~I'm content that both solutions appear to work, and in my case equally well without significant benefit either way.~~ Update: As pointed out by the Anonymous Monk below, string eval is still processed as a mini-program, leading to additional protections supplied by a more full-featured wrapper. Thanks!

(Update: readmore tags.) My detailed discovery thus far:

After playing with Module::Load I can certainly replace my stringified eval with a Module::Load::load() call, to identical function. While it's not a problem in my environment, tracing (using truss(1)), and timing wall runtime indicated that it's slightly slower to use this module for dynamic loading. This is unlikely to be a realistic limitation, although it is curious to note. (This is primarily due to @INC containing a half-dozen entries, plus my 'lib' path, leading to many ENOENT errno returns.)

I'm also unclear what problem this module attempts to solve, exactly. It doesn't really simplify my code to change:

eval "require $class";
[download]

to:

eval { Module::Load::load($class) };
[download]

given that both accomplish the same thing.

After reviewing the perldoc for Module::Load, it states:

This gives nasty overhead when you are trying to dynamically require modules at runtime, since you will need to change the module notation ("Acme::Comment") to a file notation fitting the particular platform you are on.

However, I had to do no such changing of notation when I wrote __PACKAGE__ . "::" . $opts{type} above: this is forming a string with the double-colon in module notation and passing it to eval as a string. Perhaps this was a historically unsupported feature of require, but given that it appears to work as expected, and a touch more efficiently, keeping my original code, I'm not sure this module offers much value that I can see.

Of course, there may be use-cases where the flexibility offered by detecting module vs file construct is actually necessary. If there's a platform difference I'm unaware of here (broken support on MS Windows, for instance) I'd be curious to hear compatibility issues with string eval of module-notation (I develop nearly exclusively for Unix-like systems.)

Comment on Re^2: OO factory behind simple methods Select or Download Code

Replies are listed 'Best First'.
Re^3: OO factory behind simple methods by Anonymous Monk on Dec 18, 2015 at 03:54 UTC
... However, I had to do no such changing of notation when ... you can't use require $modname without string eval because require expects a $filename since string-eval takes perl source code, $type would should be validated to prevent problems eval "require $modname; 1" is slower than require $filename; so module::load helps you use require $modname by converting $modname into filename	[reply]