Re: RegexFilenameFilter

["Daniel F. Savarese" <df...@savarese.org>]

Sorry for the delay in replying.  I was hoping for further comment from
other users.

>I noticed the 4 param RegexFilenameFilter constructor
>   RegexFilenameFilter(cache, matcher, regex, options)
>does not pass on the options to setFilterExpression.

Probably a bug.  The filter classes probably haven't been exercised
very much by users, leading me to your next comment:

>Also, we could easily have RegexFilenameFilter also
>implement both FilenameFilter and FileFilter.  The
>code is below.  I suggest we do this.

Yes, I agree.  Good idea.  This is another example of how some of
the code has seen neglect over time.  The filter classes were
never updated when FileFilter was added (ouch, that was probably a
JDK 1.1 feature!).

>A feature I found I needed was to let all directories
>through the filter and only filter the files (good for when
>you want to recurse).  This only works well for
>FileFilter.accept - for FilenameFilter.accept you would have
>to make a new File object out of the parent File object and
>the filename, which is wasteful.  It wasn't hard to extend
>GlobFilenameFilter to do this, but does anyone else consider
>it a good optional feature for the ORO package?

Could you suggest what the API should look like to enable this
(e.g., boolean flag)?

>p.s. any releases planed soon?

Right now I think we're letting incremental fixes and improvements
drive the releases.  We should put together a development plan for
the software and add an extra committer.  Most people are interested
in the regex and perl packages, but it's clear that the other stuff
is used pretty frequently.  My agenda is to bring the regex/perl
packages up to Perl 5.6 compatibility, but focusing strictly on
that is not a good idea.  Anyway, my thoughts aren't collected
right now (let go a bunch of good employees at work :(), but I'll
commit the changes you've suggested this week(end) and follow up
on an email I sent out maybe two months ago that was intended to
start the initiative for a development plan.  One of the problems
with the stuff is that most of its users are happy with the current
functionality so it's hard to generate development momentum.  It's
probably best to draw up a list of stuff we want to get done by the
end of the year (or next 6 months) and just hack away at it
incrementally until it's done.

daniel