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

[Tommy]

Having evaluated all the options on the table now for several hours, I am leaning toward the more 'simple' approach you mentioned. My rationale is that I don't want to complicate things, and martel I believe you are right that the proposed new switches would make things confusing given the already existent --dirs-only and --files-only switches. With any extra switches, it's anyone's guess what the expected behavior would be from end users.

So for now I am going to plan on throwing a warning out when list_dir() is used with the --pattern switch, for at least one release (ver 3.29), expressing to the user what new behavior to expect with the following release (ver 3.30+). I don't see too much harm in this, given that if users out there are already grepping through the results returned from list_dir() against a pattern they already provided to the --pattern switch, it's not going to upset the output they are currently getting. The end-result output would be the same.

If I did go with the other option (to add more switches), then browserUK's suggestion would be the correct approach. For the present however, I'm not leaning in that direction so much as I once was, given that I feel more confident I can start enforcing the originally intended behavior without disrupting the downstream results in current user code (in what I believe will be the majority of cases).

Thoughts?

[martell]

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!