Front page | perl.perl5.porters |
Postings from May 2008
Dr.Ruud wrote:
> Gisle Aas schreef:
>
>> my @dirs = generate_list_of_dirs_that_should_be_there();
>>
>> mkpath(@dirs); # will this do the right thing or not?
>
> Please make that "mkpath( \@dirs )".
Well that's just it. The old interface used a hokey so 1980s
first-param-is-a-scalar-or-a-reference interface. What Gisle is saying
is that you have no idea what
generate_list_of_dirs_that_should_be_there() may return. It may
therefore trigger the old interpretation, or the new, depending on the
phase of the moon.
When the discussion came up for renovating File::Path came up, the two
problems of positional unnamed parameters and scalar-or-ref could be
solved with a straight list, followed by a hashref of args to tweak the
behaviour.
I also wanted to add new functionality, such as delete everything under
the directory except for the directory itself. And I wanted it to be
easy for people to refactor their code with a minimum of fuss to get rid
of the dinky scalar/ref stuff and so on, and make calls to mkpath() and
rmtree() look exactly the same as calls to 99.9999% of other modules.
What's with the [ref] shit?
I cannot say why I made a mental blockage on introducing a new function
into the namespace. In retrospect it seems silly. If someone is going to
fiddle with the arguments to turn C<,1 ,1> into C<{safe => 1, verbose =>
1}>, it certainly would not kill them to edit the function name at the
same time to change it from rmtree to unlink_tree (or whatever, I'll be
happy to listen to a bikeshed argument on that one).
Be that as it may, I made a serious error trying to shoehorn both styles
into the one. The next release will change this situation.
David
Thread Previous
|
Thread Next