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.
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.
IExtendSelector:
* 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.
MajoritySelector:
* Nice idea.
Not practical, though. I just wanted to shake up people's thinking a bit, so that really practical containers could be realized.
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. 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: <mailto:[EMAIL PROTECTED]> For additional commands, e-mail: <mailto:[EMAIL PROTECTED]>
