Beefy Boxes and Bandwidth Generously Provided by pair Networks
Your skill will accomplish
what the force of many cannot
 
PerlMonks  

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

by martell (Friar)
on Oct 01, 2012 at 19:47 UTC ( #996724=note: print w/ replies, xml ) Need Help??


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


Comment on Re^4: Seeking your opinions on proposed patch to File::Util
Select or Download Code
Replies are listed 'Best First'.
Re^5: Seeking your opinions on proposed patch to File::Util
by Tommy (Chaplain) on Oct 02, 2012 at 20:35 UTC

    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!

    --
    Tommy
    $ perl -MMIME::Base64 -e 'print decode_base64 "YWNlQHRvbW15YnV0bGVyLm1lCg=="'

Log In?
Username:
Password:

What's my password?
Create A New User
Node Status?
node history
Node Type: note [id://996724]
help
Chatterbox?
and the web crawler heard nothing...

How do I use this? | Other CB clients
Other Users?
Others cooling their heels in the Monastery: (11)
As of 2015-07-29 11:06 GMT
Sections?
Information?
Find Nodes?
Leftovers?
    Voting Booth?

    The top three priorities of my open tasks are (in descending order of likelihood to be worked on) ...









    Results (263 votes), past polls