ant-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Stefan Bodewig <>
Subject Re: svn commit: r695402 - in /ant/core/trunk/src/main/org/apache/tools/ant: types/selectors/ types/selectors/
Date Mon, 15 Sep 2008 15:24:19 GMT
On Mon, 15 Sep 2008, Gilles Scokart <> wrote:

> Cool, I was thinking to do something like that but I was not sure
> about the class to use, and wheter it was really usefull to store
> tokenized path into an object in case we have a single include
> patterns.  I missed the fact that isDeeper was also requiring a
> tokenization.  So clearly my doubt about the usefullness was invalid
> (I was thinking that we could eliminate a tokenization only when we
> had 2 or more includes pattern on which we loop).

True, even with a single include pattern (which we always have
since "no include pattern" gets translated to "**") the file's name
would get tokenized twice, as would the include pattern itself.
> However, with this change you are storing pattern and values in the
> same class.

Is your main problem the name of the class?

> I think we should have two classes.  Both need to tokenize a
> string using the same tokenizer, but what you can do with both is
> different.

I'm not convinced their behaviour is really any different, every
name is a pattern as well.

IIUC you'd prefer to move the match methods into a pattern specific
class - and probably change the left and right side in the new
matchPatternStartOf method so that the new method is on class
representing the pattern (all delegating to SelecotrUtils).  This
would class share the tokenization (delegated as well), depth and
contains logic with a different class used for paths without any

We could do that, but I don't really see that much benefit.


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

View raw message