in reply to Seeking your opinions on proposed patch to File::Util

hum... 

my @recurse_ignored = $f->list_dir('/dir/', '--recurse','--pattern=\.t
+xt$');
my @pattern_and_recurse_ignored = $f->list_dir('/dir/', '--pattern=\.t
+xt$ --recurse');
my @no_files = $f->list_dir('/dir/', qw/--pattern=\.txt$ --recurse /);

[download]

I would suggest a different notation instead, to use bash "--longname-option" notation inside perl looks ugly (in my opinion)

my @array = $f->list_dir('/home/moo/','--pattern=\.txt$', '--recurse', '--files-only');

I propose this form instead for the same line:

my @array = $f->ls(files, '/home/moo/','\.txt$', 0);

Much easier to write, read and understand, isn't?

list_dir is not a bad name at all, but if you want to obtain a list of files, to use a function named list_dir can sound a little strange

the third argument optional (an integer, or even a range like 1..3) could be equivalent to find -maxdepth num. Recurse should be the default probably, cause you don't need to load a full perl module to do the same job of opendir, readdir in more lines (or when you can simply could wrote `ls *.txt` for this). You expect to be rewarded with the possibility to do something more sophisticated (like to search only for four levels of subdirectories, or in the third subdir) when you take the extra effort to load a module.

I would suggest also to avoid to write "my ($var) = x" in the documentation when you can write simply "my $var = x". The first idea suggests a list context for the vars, for both $scalars and @arrays, and again seems a little more difficult to read.

Replies are listed 'Best First'.
Re^2: Seeking your opinions on proposed patch to File::Util
by Tommy (Chaplain) on Oct 01, 2012 at 01:35 UTC

    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 "."
)

    [download]

    ...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.

    --
    Tommy
    $ perl -MMIME::Base64 -e 'print decode_base64 "YWNlQHRvbW15YnV0bGVyLm1lCg=="'
[reply]
[d/l]
[select]

In Section Seekers of Perl Wisdom