ant-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Adam Murdoch" <>
Subject RE: [WIP]Selectors
Date Tue, 05 Mar 2002 10:39:06 GMT

> -----Original Message-----
> From: Bruce Atherton []
> Sent: Tuesday, 5 March 2002 4:11 AM
> To: Ant Developers List
> Subject: RE: [WIP]Selectors
> 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
> DirectoryScanner.
> 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.

This is a good plan.  Might not be 100% achievable, since we have to leave
the API of DirectoryScanner intact - that is, all public and protected
methods will have to remain, and continue to behave more or less the same
way.  However, that doesn't mean we can't gut those methods, and move the
code somewhere more appropriate.

> >PatternSet:
> >
> >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.

Swap it around.  A pattern is-a selector.  A pattern set is-a selector.
That is, a selector is a generalisation of pattern and pattern set.

> 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.

Is there?  Maybe to vendor or project specific tasks, but not something
general like a selector container.


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

View raw message