Front page | perl.perl5.porters |
Postings from May 2008
Re: File::Path::mkpath() incompatiblity in perl-5.10
Thread Previous
|
Thread Next
From:
Gisle Aas
Date:
May 15, 2008 09:37
Subject:
Re: File::Path::mkpath() incompatiblity in perl-5.10
Message ID:
D3D2D930-993C-4D35-9A13-16BE44AFC506@activestate.com
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.
--Gisle
Thread Previous
|
Thread Next