On Apr 1, 2005 12:03 AM, JupiterHost.Net <[EMAIL PROTECTED]> wrote: > > 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 :)
Yes it is, but not if you don't have the original module in @ISA. I believe--although I'm not certain--that my suggestion will work as stated. [snip] > 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. > Lee, It's generally best to provide as real-world an example as possible when asking for help on this list. Code doesn't confuse things--or people--around here. We all look at the code you send and comment on it. I still have to say, though, that you're not getting the most out of your modules here. If you find yourself needing the same thing thing in two different places--that is, you're using Digest::MD5 in a module, and then exporting Digest::MD5 routines directly into main as well--you're not being as efficient as you can. Either calculate all you checksums in main, or claculate them all in your module. The whole idea of modules is to increase maintainability and decrease complexity by allowing you to segregate functionality. Here, you're scattering, and perhaps dublicating, functionality. And if the next version of the module changes something important, you have change both Foo.pm::import and any place you call md5_base64 in main. I hope I'm being clear, here. It boils down to this: if you're doing enough with Digest::MD5 that it's worth importing it into the module, offload all the md5 work onto the module. If you really need Digest::MD5 in main, do all the checksums in main, and pass your data off to Foo.pm either before or after the checksum is computed. Manipulating import and @ISA is a useful way for parents and children to handle dependence and inheritence behind the scenes, but if we find that we're using it to export routines to main, or for communication between modulees that don't shre the same namespace, it's usually a big, flashing, neon sign that says "fuzzy logic." But maybe this is getting off topic from perl and into general programming philosophy. HTH, --jay -- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] <http://learn.perl.org/> <http://learn.perl.org/first-response>
