Assuming that your import() does what you think it does--and I don't have time to test it, but as long as you're USEing it anyway, why not just write a wrapper instead of the pass-the-import nonsense--you
Because then I have to add and manage a wrapper for each new function and keep up with the parent module's changes, It'd be much nicer to pass it all to theparent so its 100% the same arguments 100% of the time :)
haven't called it in test.pl, or anywhere else, or defined it as a standard export. You might try either:
in FooTest.pm add : @EXPORT = qw(&import); # in test.pl, call FooTest::import();
Before you call md5_base64. Otherwise, how is it getting imported?
perldoc -f use perldoc perlmod perldoc Exporter
import() is special :)
try calling your function something else, too. Reimplementing built-ins isn't trivial, and it's a bad idea unless you really know what you're doing.
I'm not reinventing it I'm using it as it was intended :)
Also, from a more general perspective, think about what this is really worth to you and and your project in terms of man hours. You 1) have the function funk() that provides identical functionality and 2) could
Those are just examples to illustrate the problem by calling the md5 function different ways. I've purposefully left the actual project detaisl out so as not to cloud th eproblem :)
easily rewrite funk to be called md5_base64 if you're attached to the name for some reason:
sub md5_base64 {
shift;
Digest::MD5::md5_base64($_);
}
Again I'd ahve to do that for each function the parent EXPORT_OK's and maintain any changes, I'd rather use the Exporter/import() paradigm to do it dynamically.
or in main:
sub md5_base64 { shift; FooTest::funk($_) }
but then its not modular :)
No muss, no fuss. There's a reason that what you're attempting is difficult: it's dangerous, from a dependency standpoint. In fact, it
Why is it dangerous? From a dependency standpoint it makes it much more portable and compatible because you don't ever have to worry about watching versions or what the parent does.
For example:
use Parent qw(foo); print foo();
use Parent::SubClass qw(foo bar); print foo();
Now you could import foo directlty from Parent.pm or maintain a
sub foo { Parent::foo(@_) }but what if foo is ever removed, or renamed or they add one called bar()?
NOw you have to watch for those changes and make them, what if Parent verison 1.2 has foo but not bar and verison 2.0 has bar bu tremoved foo?
Now Parent::SubClass also hase to map verisons to EXPORT_OK's and check them and on and on.
reverses the whole notion of dependency. Modules are intended to be,
well modular. You should be able to change the logic of a module, and
the caller shouldn't care, as long as the interface remains the same. A module maintainer should have to worry about what the maintainer of
the main routine needs from the modules the module calls, or the
modules called by the modules called by the modules called by Larry
Wall's father's best friend's college roommate. If you want a routine
to be accessible from your module, provide an interface for it. And
if there's a cpan module that does exactly what you want, use it;
that's what it's there for. Don't add uneccesary logic; don't require
FOO::BAR to require FOO::BAZ when you can just use FOO::BAZ in the
in this case Parent::Subclass already doe suse Parent; for its goods, Its subsclassing not making stupid random use's
first place and save yourself, time, typos, and file descriptors. If you really do need inheritence, learn OO, and get real inheritence.
The Parent is function based and OO based so I must do both, this has nothgin to do with inheritcance but import()/export_to_level() You don't export OO methods and I can't force the Parent Module to make it 100% OO based.
Thanks for your input, I beleive I may have not been clear aboutthe goal and apologize if it confused you.
-- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] <http://learn.perl.org/> <http://learn.perl.org/first-response>
