develooper Front page | perl.perl5.porters | Postings from May 2008

Re: File::Path::mkpath() incompatiblity in perl-5.10

Thread Previous | Thread Next
Gisle Aas
May 15, 2008 09:37
Re: File::Path::mkpath() incompatiblity in perl-5.10
Message ID:
On May 15, 2008, at 16:31, David Landgren wrote:

> Gisle Aas wrote:
>> On May 14, 2008, at 23:53, David Landgren wrote:
>>> Hmm. Sorry about that. I'm working on a more robust approach that  
>>> will put an end to all this.
>> Could you at least indicate what this more robust approach would be?
> It's quite simple, basically, don't try to infer anything about the  
> second param, just its presence.
> The old style is triggered by any of
>     - one parameter passed
>     - two parameters passed and second is numeric
>     - three parameters passed; second and third parameters are numeric
> The mistake was to see if the second param was numeric (as per your  
> "verbose" argument). So the new way is merely:
>     - one parameter passed
>     - two parameters passed
>     - three parameters passed and third parameters is numeric

This scheme makes it really complicated to describe what the  
interface to mkpath() is, and make the new style interface without  
hash as final arg quite inconsistent. It only works if you pass 1 or  
4 or more directory names to be created, of 3 where the 3rd name  
isn't numeric.  I find this really ugly.

>> I really want an mkpath() function in 5.10 that's 100% compatible  
>> with the interface documented in 5.8.  The only way I can see that  
>> happening
> So do I; I thought I had done so. Despite your misgivings, I still  
> think it is possible.

I agree that the new rules above make it compatible with 5.8, but the  
cost is to make the exceptions in the new style interface quite  
strange and one where you easily produce buggy programs.  Consider:

     my @dirs = generate_list_of_dirs_that_should_be_there();

     mkpath(@dirs);  # will this do the right thing or not?

>> is if you require a hash ref as the last argument to trigger the  
>> new interface,
> If the routine is called with four or more params, it must be the  
> new style, because the old style only looked at three params at the  
> most.
> No promises were made either way regarding the handling of  
> arguments beyond those documented, if mkdir('foo', 1, 0755, 'bar')  
> now creates four directories instead of one, it's because of a  
> latent bug in the original client code, since the programmer did  
> not read the documentation correctly.
> I don't think we need to bend over quite so far in order to  
> maintain backwards compatibility, only for code that respected the  
> API.
> > or that you simply move the new interface to a new function
>> name and leave the old interface alone.  Using the name make_path 
>> () for the "modern" interface seems like an improvement in  
>> readability as well, and would be my preferred approach.
> I wish I had received this feedback a year ago. There might be code  
> out there now that relies on the new style mkpath(), so it can't be  
> stripped out now.

I wished I've noticed this then too, but I do belive it's better to  
fix this mistake now.  If you silently (or with a warning) continue  
support new style mkpath with {} at the end I don't belive there is  
that much code that would break.  I would also guess that most calls  
to mkpath() only pass in a single directory name and that code should  
be compatible regardless.


Thread Previous | Thread Next Perl Programming lists via nntp and http.
Comments to Ask Bjørn Hansen at | Group listing | About