You’ll have to ask DJ that. I just thought it an interesting scripting problem. 
And your skills are amazing, almost scary!
I wonder where Micky Mudge is, he used to have this column in Personal Computer World. He’d be at home here.
It is a developer’s personal preference rather than an actual problem. I don’t like to have an handler for every purpose but less handlers that can do multiple different things depending on the given parameters.
Just one more for fun using brace expansion
do shell script "cd $HOME/Desktop && ls *.{,txt,csv,xls} &2>/dev/null"
You should really have a looksie at the capabilites of bash 4.0 It is amazing, they have turned brace expansion into something like a combinatorics engine!
As for the handlers:
I figured a set of handlers like this:
one for finding folders in a subtree
one for finding files by extension
one general one, where you can specify whatever pattern you like in a subfolder, also an empty one.
one very easy one, where you can specify begins with, ends with, contains, and exists. Keeping it in thread with the grammar for the first one
maybe one for finding folders, that uses wildcards directly.
one for finding all matching files in a subtree as above.
one handler that converts a list to hfspaths fast, with the correct volume name.
The handlers returning files, should just return files, and have a with invisibles option.
It is maybe to much? What do you think, should folder, and file be parameters? That halves it, then we end with subtree, and folder as the range?
What do you think? -I want to make a set of good easy to use handlers, as few as possible, but covering the area good, with consistency among them.
I wonder about a handler looking like this:
to filelist({searchtype:folder,range:"folder",posixPath:"thePath",predicate:"searchpred",pattern:"pattern",invisible:"no"})
since it is a record, you can get by, by default values and end up with this:
to filelist({posixPath:"thePath",pattern:"pattern"})
With default values for the other parameters, robustness for the posix path, so you can feed it a hfs path.
searchtype defaults to file (other legal value folder)
range defaults to folder (other legal value subtree)
predicate defaults to “regexp” then pattern should have regexp. for any other value regexp in the pattern throws an error. the extension is also given in the pattern, when extension is given as predicate.
Other values be “starts with”, “ends with”, “contains”,“exact”,“extension”
with extension, the pattern may be a list, if more than one extension is given, a string not a fault for a single extension.
includeinvisble, optional, defaults to false. (Yes and no should be allowed).
What do you think about that, collecting it all in one handler, leveraging over the fact that a record makes up for optional parameters?
Does coalescing it all into one handler make for too much complexity, or do you think this is better than several handlers? I am also pondering about specifiying the result type as hfspaths contra posixpaths, but I feel that is one to much.
Edit
I’ll toss in the resulttype as well, and itemkind as another predicate of a filelist.
Sorry guys
I missed all the other threads in my post after I post the link to the VBA example on my site
Go read them tomorrow, thanks all