in reply to Re^2: design the open function
in thread design the open function

I have a number of perl scripts which inturn contains a number of open functions.now... It is time consuming to change in each and every file.

This is approximately the reasoning I guessed you were using. It's flawed reasoning, because it contains a false economy.

For each script that you have, it will take you about 45 seconds to add an include or use line at the beginning (to pull in your custom function), run a search and replace (to turn open into mypackage::open or somesuch), and save, then you have to test each script, but probably everything will just work.

If you do it the other way, it will take you 30 seconds to add the include or use line at the beginning that causes open to be redefined, and save, then you have to test each script. So you save fifteen seconds per script. However, there will probably be unforseen problems with some of the scripts that will cause weird bugs and result time spent debugging, which will more than eat up your saved seconds. What is worse, next month or next year when you try to add a feature to one of your scripts, and you descover that your changes don't quite do what you thought they should, you'll at first think your changes are wrong and waste time trying to debug that, only to discover that in fact it was your redefined open function that caused the problem. Then you'll have to revisit this issue, put the open function back the way it was, and do what you should have done.

Do it right in the first place. Spend the extra fifteen seconds per script and do the search and replace. It will save you a lot of time.


Sanity? Oh, yeah, I've got all kinds of sanity. In fact, I've developed whole new kinds of sanity. Why, I've got so much sanity it's driving me crazy.