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

[Tommy]

pvaldes, your ideas are good, in hindsight. However this module and its interfaces were originally written in 2002. Many people and businesses are using the code (they even use it on the NASDAQ). I can't completely change the way calls work. However it might be possible to redesign several interfaces so that they work both in the current way and also in a way that is more consistent with "modern" interface styles, for example, the styles we see in DBIx::Class. This just requires more logical branching in order to handle different inputs, and that means more overhead...a tradeoff I would be forcing on users when some of them might not want it. Decisions, decisions.

I've considered rewriting the whole thing in Moose, and consulted Ovid about it. The end conclusion was to leave it alone and not expose implementation by creating another namespace such as "File::Util::Moosed"

If I was designing it brand-new today, I would still keep the name of list_dir, and provide an "ls" alias (which I may still do), and the syntax would be something more like the following:

$f->ls(
   dirs       => [ $dir, $dir2, $dir3 ],
   recurse    => 3, # go three directories deep
   files-only => 1, # return only file names (no dirs)
   match      => [ qr/txt$/, qr/!^\./ ] # all text files that don't be
+gin with a "."
)

...and File::Util would have to examine more carefully what each argument was, and intelligently handle the things it gets, regardless of what order they come in or whether or not they are necessarily a balanced key-value pairing. One example would be to automatically recognize listrefs of pre-compiled regular expressions as a valid argument, and just apply each regex as a pattern to match against.

Such things might materialize in the future as I come closer to figuring out how to implement such features without breaking existing ones. I'm always open to suggestions regarding the backward-compatible introduction of new features, and patches of course.