ant-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Bruce Atherton <>
Subject RE: [WIP]Selectors
Date Mon, 04 Mar 2002 18:11:23 GMT
Arrgh, slip of the finger sent that prematurely. To continue.

At 09:42 PM 3/4/2002 +1000, Adam Murdoch wrote:
>* The guts of this selector look suspiciously like the guts of
>DirectoryScanner.  Can you refactor the matching code into a ScannerUtil
>class that both FileNameSelector and DirectoryScanner share? (it's mostly
>all static, shouldn't be a drama).

I would love to, but in a slightly different way.

I think it is silly for DirectoryScanner to be deciding which files are 
included in a fileset. It should just be a driver, reading the file entries 
and passing them into the fileset/patterset/selector to make that decision. 
Selectors moves some of that responsibility into the selector classes, 
where it belongs, but the includes and excludes are still handled in 

That could be changed, though. If creating an include or an exclude didn't 
just add the PatternSet.NameEntry, but also created a filenameselector in a 
container that matched what patternset does (see the note in selectors.html 
for an idea), then eventually the responsibility could be shifted entirely 
to the selectors.

But that is a fairly large change and there may be disagreement about how 
much it could affect others from a change in the API (does anyone else use 
match(), for example?), so I'm concentrating on the low impact changes first.

>* Hmmm.  setAttrib9()?  Can we use the same pattern for extensibility that
>the file filter code uses?  Whether it's a good or bad pattern, we need
>consistency.  I suspect that there's a good candidate somewhere there for a
>base class gets used by the mapper, file filter, and selector extensibility
>beans, to take care of 90% of it.

Love to. I wasn't aware of a pattern already being available. I'll take a 
look at it. Thanks for pointing it out.

>* Nice idea.

Not practical, though. I just wanted to shake up people's thinking a bit, 
so that really practical containers could be realized.

>I think you're overloading a little by adding the nested selectors to
>PatternSet.  Let's leave PatternSet as a set of patterns, and add a new
>selector container data-type (like AndSelector, say).  Get FileSet to extend
>that, rather than PatternSet.

Hmm. I see what you mean. I've always thought of selectors as defining a 
pattern, but you could also see them as an alternative to a pattern. I'm 
not sure which is more correct. The benefit to your view is that we don't 
get patternsets within patternsets. The disadvantage is that patternsets 
can be top level tasks, and there is a resistance to introducing new ones.

>We probably still want PatternSet to *be* a selector, so rather than have
>PatternSet extend AndSelector, we should have it implement ISelector, as a
>specialisation of FileNameSelector.  FileSet will need to deal with
>PatternSet specially, to remain backwards compatible (since the PatternSets
>are aggregated before they are evaluated).

As I said, what I really want to do long term is move to where include and 
exclude, while appearing to work the same on the surface (ie, to the APIs), 
are really implemented as selectors under the covers. But you are right, 
that can be done just with implementing the interface.

Thanks for all your comments, you've raised some very good ideas and 
interesting points.

To unsubscribe, e-mail:   <>
For additional commands, e-mail: <>

View raw message