You are viewing a plain text version of this content. The canonical link for it is here.
Posted to oro-user@jakarta.apache.org by Dan Lipofsky <dl...@kurion.com> on 2001/02/22 01:51:40 UTC

RegexFilenameFilter

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

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

  /**
   * Filters a filename.  Tests if the filename EXACTLY matches the pattern
   * contained by the filter.  Only the last component (File.getName()) is
   * examined.
   *
   * @param file  The File object to run the filter against.
   * @return True if the filename EXACTLY matches the pattern, false if not.
   */
  public boolean accept(File file) {
    synchronized(_matcher) {
      return _matcher.matches(file.getName(), _pattern);
    }
  }

Alternately we could have both RegexFilenameFilter and
RegexFileFilter, GlobFilenameFilter and GlobFileFilter, etc.
It seems better to just implement them both in one class
except it might be confusing to have something named
*FilenameFilter that implements FileFilter.   Also see
my next point.

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?
- Dan

p.s. any releases planed soon?