2008/5/17 David Landgren <david@landgren.net>: > 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. Lots of people reviewed your proposals, including me, and noone suggested this, so if a "serious" error has been made responsibility for it does not rest solely with you. yves -- perl -Mre=debug -e "/just|another|perl|hacker/"Thread Previous | Thread Next