Re: general rule for using use

The result is that just by using one module you can pull in half of the code base.

So, is that a problem? Or asked differently, what kind of problem are you actually trying to solve?

Does your application use too much memory? or is the startup time too large?

If you don't have a problem, don't worry. Remember Donald Knuth's wisdom: "premature optimization is the root of all evil".

The reason that this "don't use stuff that you don't need the namespace of" thing sounds weird to me is that I don't think it works. In your example above, $order comes somewhere. Wherever it comes from, that module actually loaded the module Order - probably at compile time, and unconditionally. So it gets compile once anyway - and if you use use it multiple times from different places, it's still only compiled once.

Comment on Re: general rule for using use Download Code

Replies are listed 'Best First'.
Re^2: general rule for using use by perl5ever (Pilgrim) on Apr 08, 2009 at 22:38 UTC
Thanks for reminding my of Knuth's sage advice. I think what I'm getting at is that using `Order` in `X` is misguided. When we say that `doSomething()` operates on an `Order` object, we are really saying that it operates on an object that behaves like an `Order`. It could be an instance of `Order` or an instance of a sub-class or just a mocked-up object that implements enough of the methods of an `Order` to make it look like an `Order` to `doSomething()`. There may be no harm in including it, but on the other hand I can't think of a compelling reason to do so. If a real instance of `Order` will get passed to `doSomething`, then the caller can be responsible for ensuring that the `Order` name space is loaded. Perhaps I forgot to mention that this particular application consists of 800+ modules, and all of that unnecessary module loading is a big drag on unit testing.	[reply] [d/l] [select]
Re^3: general rule for using use by targetsmart (Curate) on Apr 09, 2009 at 05:38 UTC
Good question this ++ for that. I often think like this and some times I write my own simple module(in terms of number of lines of code) for solving problems rather than using a third party one, since there are lot of dependencies and it is really painful, it pulls thousands of lines of code un-necessarily, but it might be designed to work in all platforms, much reliable, etc, I seriously don't want to complain any third party module, this is my opinion What you are trying to do? UNIT Testing or adding any new feature into the code?. if UNIT Testing, better don't disturb the flow of the code, just test as it is. if you are planning to add any new feature or if you want to re-engineer the entire code(since you don't like to load 800+ modules and you think it can be done in a simpler way), if you know the clear requirements, better write you own code which uses simple set of modules which meets your requirement(provided if you have time, if you don't have time, just understand the existing code base and find out why they have done like that, nothing would have been done for no reason, better note down drawbacks and do it later when you have time). Vivek -- In accordance with the prarabdha of each, the One whose function it is to ordain makes each to act. What will not happen will never happen, whatever effort one may put forth. And what will happen will not fail to happen, however much one may seek to prevent it. This is certain. The part of wisdom therefore is to stay quiet.	[reply]
Re^4: general rule for using use by drench (Beadle) on Apr 09, 2009 at 17:48 UTC
Or maybe you've switched the calling code to use the new 100% compatible and much faster `Order_XS` module. Yet here's module X, still pulling in the now-unused pure-Perl `Order` module. It's code it doesn't need, but everything keeps working, so nobody cares (or even notices). A couple years later you're installing the app on a new server, and the sysadmin asks, "do I need to install this `Order` module?" And you say "no I switched to `Order_XS` years ago. Don't bother." And then...	[reply]
Re^3: general rule for using use by moritz (Cardinal) on Apr 19, 2009 at 11:36 UTC
Perhaps I forgot to mention that this particular application consists of 800+ modules, and all of that unnecessary module loading is a big drag on unit testing. If it's only testing that's slow (and not the "real" uses of your program, whatever that may be) maybe the right thing to do is to change the testing? For example load the app only once in one process, and then read the test files in that process and run them in order?	[reply]