commons-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Ola Berg <ola.b...@arkitema.se>
Subject RE: [IO] filefilter sub-package
Date Thu, 25 Jul 2002 10:37:09 GMT
>> Secondly, does anyone see a reason why some of these can\'t be 
>> java.io.FileFilters rather than java.io.FilenameFilters. 

No.

>> Also, should the FilenameFilter version also be managed somehow?

>Are FilenameFilters and FileFilters useable
in all the same contexts?  

Not in all contexts. Even if SUN has updated so that it is always possible to use FileFilter,
any third party might not have done that. 

>If not, then we need to maintain the FilenameFilter 
>version--perhaps even within the same
>class (unless the interface is incompatible).

Provide a method (with corresponding adapter class) that adapts FileNameFilter to FileFilter.
Change the existing FilenameFilters so that they support both interfaces, maybe by letting
them extend an abstract class which will take care of the adaption:

public abstract class AbstractFilenameFileFilter
implements FileFilter, FileNameFilter
{
    /** Defined in FileFilter */
    public final boolean accept( File f){
        return accept( f.getParentFile(), f.getName());
    }

    /** Defined in FilenameFilter */
    public abstract boolean accept( File dir, String name); 
}

If I am not totally wrong here: just adding the \"extends AbstractFilenameFileFilter\" on
the existing ones should do the trick, unless they have a tricky extends-hierarchy as they
are now.

/O

--------------------
ola.berg@arkitema.se
0733 - 99 99 17

--
To unsubscribe, e-mail:   <mailto:commons-dev-unsubscribe@jakarta.apache.org>
For additional commands, e-mail: <mailto:commons-dev-help@jakarta.apache.org>


Mime
View raw message