I'm not sure if this applies to cullers, but having both an include and an exclude does make logical sense -- I might want to include every member of a group except certain members of a sub-group. e.g., I might want to include all files of the form *Test.java, but exclude those that live in a directory named example.
I'm not sure if there's an analogy for cullers, though. :)
Cheers,
Chris Greenlee
David Rees wrote:
On Tue, 20 Mar 2001 11:57:35 -0800, David Rees wrote:
On 19 Mar 2001 10:23:49 +0100, Stefan Bodewig wrote:
David Rees <[EMAIL PROTECTED]> wrote:
While we are on the subject, is there really a reason for the excluded and non-included parts of DirectoryScanner?
I've never seen anybody use it, but it has been there from the start - so we could potentially break some environments if we'd drop them.
The problem is I would like to make a nice simple culler interface like shouldInclude. But to support these three layers of "inclusion" I need to have shouldInclude and shouldExclude which really doesn't make sense to me. As a small note, the naming inside DirectoryScanner is not consistent. "filesIncluded" returns files included and not excluded (as opposed to files included).
Actually, what I really think is happening is that there needs to be a shouldScan for directories which is what the shouldInclude is really being used for (to avoid descending on directories that can never contain files to match). Then nonIncluded becomes non-scanned, excluded is scanned-but-included and included means scanned-and-included. Maybe do this and keep the old APIs for backwards comparability?
Well, I dived into the code some more and I think I (slightly?) misrepresented the situation. My core problem is with the distinction between notIncluded and excluded. This requires knowledge at the Scanner level of include/excluded which doesn't make sense outside of patternsets. As an example, the culler interface I want is just "shouldInclude" but to support the excluded set I need a "shouldExclude". That doesn't really make sense for things like a attribute culler. Also, "shouldInclude" is a misnomer because the scanner only adds a name to the include set if the name passes both shouldInclude and shouldExclude.
My current gut, do-no-harm feel is to support both shouldInclude and shouldExclude in the culler API. But the average culler (e.g. every culler but path culler) always returns false for shouldExclude so that the average culler developer only thinks include or not include?
d
