Re^2: general rule for using use

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.

Comment on Re^2: general rule for using use Select or Download Code

Replies are listed 'Best First'.
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]