However, I also wanted to get rid of the stuff in @EXPORT (by default) and make it instead @EXPORT_OK, especially since if using the object form we don't even want the one-function-call form.
I got so bogged down in making a smart backward-compat module that I never did release the thing! We discussed issues such as using version strings vs literal strings that look like version numbers, and some ideas on how to get it to work.
Well, now I want to get back to that, and solve the problem more generally. How about an import() that I can require into my code and have version-sensitive imports or other changes? This will provide a simple way for a module's author to give backward compatibility without being enslaved to old interfaces.
Before getting back to the issues of version strings and comparisons and otherwise how to drive the component, I want to investigate how the thing should work in the first place.
Idea: my new import() scans for a version number (or lack of) in the import list, sets the @EXPORT etc. package variables, then jumps to the original to do the real work.
Can a module tell what version each calling module asked for? Sure, use a hash. But too much overhead! Better to simply import different functions into each caller depending on the behavior they wanted. So, I need alias abilities: import foo_2 or foo_3 as caller::foo. I don't think Exporter::import has any such ability.
Clues, anyone?
—John
In reply to A better import() - version sensitivity by John M. Dlugosz
| For: | Use: | ||
| & | & | ||
| < | < | ||
| > | > | ||
| [ | [ | ||
| ] | ] |