Return-Path: Delivered-To: apmail-jakarta-commons-dev-archive@apache.org Received: (qmail 54742 invoked from network); 29 Jul 2002 08:36:33 -0000 Received: from unknown (HELO nagoya.betaversion.org) (192.18.49.131) by daedalus.apache.org with SMTP; 29 Jul 2002 08:36:33 -0000 Received: (qmail 405 invoked by uid 97); 29 Jul 2002 08:37:02 -0000 Delivered-To: qmlist-jakarta-archive-commons-dev@jakarta.apache.org Received: (qmail 370 invoked by uid 97); 29 Jul 2002 08:37:01 -0000 Mailing-List: contact commons-dev-help@jakarta.apache.org; run by ezmlm Precedence: bulk List-Unsubscribe: List-Subscribe: List-Help: List-Post: List-Id: "Jakarta Commons Developers List" Reply-To: "Jakarta Commons Developers List" Delivered-To: mailing list commons-dev@jakarta.apache.org Received: (qmail 358 invoked by uid 98); 29 Jul 2002 08:37:00 -0000 X-Antivirus: nagoya (v4198 created Apr 24 2002) Date: Mon, 29 Jul 2002 04:36:39 -0400 (EDT) From: Henri Yandell X-X-Sender: To: Jakarta Commons Developers List , Ola Berg Subject: RE: [IO] filefilter sub-package In-Reply-To: Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-Spam-Rating: daedalus.apache.org 1.6.2 0/1000/N X-Spam-Rating: daedalus.apache.org 1.6.2 0/1000/N On Mon, 29 Jul 2002, Ola Berg wrote: > Hen writes: > > >On Ola Berg\'s suggestion I worked at an Abstract class which merges the > >filename-filter and file-filter interfaces together. > > Cool. But you could have asked, and I could have done it. Anyway... Sorry, I was bored and looking to play with something :) > > >The only fault with > >the one Ola provided was that it only fit if all > >subclasses wanted to be > >FilenameFilters. > > Well, yes, but I didn\'t think of it as a fault, but as a way of > enforcing it\'s role as an adapter superclass for FilenameFilter > classes wanting to upgrade themselves to FileFilter classes. In order > to prevent accidental misuse I made the accept( File dir, String > fileName) method abstract, meaning that any concrete descendant _has_ > to define an implementation for the FilenameFilter interface. It slams into the two classic examples of File-Filters though. The first is that of a filename-extension filter. This works best on filenames as it doesn't care about the actual File object, just its String name. The second is directory filter. This works best on File objects as it wants to know if that File object represents a directory. If it has to define a FilenameFilter interface, it'll define it the same way every other natural FileFilter interface will. Probably this is unnecessary, but it feels poor to choose one implementation other the other. Maybe there could be two abstract classes, one for each type of sub-class, with a common interface between them. > > But before I say too much, I will check out your solution and see for > myself. > > BTW, is there a need for doing his adaption dynamically too? My > solution was proposed as a static way of doing it (simply add > extends... in the source code). If you mean the poorly named DelegateFileFilter, it's because three of the filters currently there are CompositeFilters, linking file-filters together. They have to have an interface to work upon - Jakarta-FileFilter, however there also has to be a way of taking an existing FileFilter/FilenameFilter from java.io and working upon that, thus the DelegateFileFilter. There's probably a more elegant solution? Hen -- To unsubscribe, e-mail: For additional commands, e-mail: