On Apr 1, 2005 4:04 PM, JupiterHost.Net <[EMAIL PROTECTED]> wrote: > > Are you even serious? I sent the exact code that reproduced the problem. > You said you didn't have time to run it which is fine, > but it was there :) >
The code you sent 1) was oversimplified and 2) presented you as creating a module to both use a function from another module in you module and allow you to use the borrowed function in you main routine to encode the same string repatedely using the same function called three different ways. Only two worked. I think, though, that you final code will not call the bare function, and will not recalculate the checksum for the same string over and over again. > > 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 > > I think you're wrong, I beleive I'm getting the most out of it :) > > > in two different places--that is, you're using Digest::MD5 in a > > nope just need it in one place, again I think you misunderstand the > idea. that you said something about me never even calling import() > showed you need a better grasp before you can disect it :) > I understand import just fine. You were the one having a problem with it. I suggested a remedy for you your code *as you presented it*. There were several things wrong, and I guessed you were trying to roll your own function to duplicate the built in. Many beginning programmers do. So I told you how to do it, and I told you it was a bad idea. I misjudged what you were attempting, that's all. > > module, and then exporting Digest::MD5 routines directly into main as > > well--you're not being as efficient as you can. Either calculate all [snip] > > 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 could achieve the above 2 ways: > > 1) the way I was looking for which passes imports it doesn't have to > the Parent->import mehtod = no maintenance due to changes in the Parent > (IE adding functions, removing functions) > > 2) the first way you suggested which I had already mentioend I wanted > to avoid, because I'd have to maintain each funstion whwnever the Parnet > changed , at that point it would be to lame to do so much work for but > #1 = no work and it works great! > > I think you misunderstand completely what I'm trying to do. The example > code illustrates it nicely. > > The solutions other presented allows it to work flawlessly in an > efficient and 100% compatiblity/0% maintainablilty manner as I was > looking for. Well, I think you said it all there: 100% compatibility / 0% maintainability. Because that's what you've got. If that's what you want, ok. But think a little bit about the convoluted namespace you created to get that function in there. Think also about this: why have you put this code into a module? So you can reuse it, presumably. Or at least that's the assumption I'm working with. Maybe you're even going to share your module with other people. Now let's say I maintain Digest::MD5, and tomorrow, I decide that the function isn't going to be called 'md5_base64' anymore, because I got sick of typing it. From now on it's going to be 'md5_64'. You now have to go through and fix your module to make it export the new function name. Then you have to go through every program that uses the module, and change every occurance of 'md5_base64'--thank god for regex! If you had imported the function directly in the main program, though, you'd only have to change that code. Better still, what if you'd written your own function called Jupiter_md5, and put it in your module. And why not? You need the code in the module anyway, for something else. Why not offload some more of the logic onto the module? If you'd done that, you would have to make a few changes in *one* place, and *every program* that used the module would be fixed. This is why modules, and even moreso objects, are such powerful programming tools: 1) reusability, and 2) insulation. best, --jay -- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] <http://learn.perl.org/> <http://learn.perl.org/first-response>
