Re^4: Seeking your opinions on proposed patch to File::Util

[martell]

in reply to Re^3: Seeking your opinions on proposed patch to File::Util
in thread Seeking your opinions on proposed patch to File::Util

Hi

I think throwing a warning out for something that will change in a future release isn't good practise. I personally debug until all errors and warnings are gone. In some coding environments the code repository even tests this in an automated way before accepting a commit. Your warning will disrupt this. The closest thing I've seen before is a warning that you are using an experimental feature. And that is a different situation then you are facing.

If you are really worried about code disruption, then you should not change the behaviour of the switch --pattern and use a new switch e.g. --fileter-pattern. Put the new behaviour in the new switch and throw a warning on the old --pattern switch that it is depreciated. This is the only good way to change fundamentally a behaviour with the least possible disruption for coders. Old is old and new is new. Simpler is not possible.

If it is crucial for you to change the switch --pattern, then I think it is better to change the behaviour according following plan:

Step 1: Put up a big warning message in the documentation of the switch --pattern that the behaviour will change in the next release. Put the new behaviour already in on a different switch e.g. --filter-pattern so coders can already code according the new behaviour.

Step 2: The release after, you make the switch --pattern an alias of --filter-pattern. On top of that put the old behaviour in a new switch, e.g. --pattern-no-recursive and throw a warning on the use of this switch saying that it will be deprecated on future release x. In this way people can keep the old behaviour with a simple change in their code while the warning will remind them this must be changed.

Step 3: The release after, you remove the old behaviour and then, according taste, you could depreciate the switch --filter-pattern in future release by putting first a warning and then removing the switch.

You probably now feel why I think it is better to use a new switch if you are really serious about code disruption...

And at last, but maybe the biggest advise: whatever you do, put the changes clearly in your documentation of the switches!

Again, this is only my humble 2 cents.

Martell

[Tommy]

Thanks for taking the time to write that up, martel. I'll follow up later on when I've put the changes in place. I appreciate your input, and am taking it /fully/ into consideration as I move forward.

Thank you again!