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:36:53 GMT

> -----Original Message-----
> From: Bruce Atherton []
> Sent: Tuesday, 5 March 2002 3:58 AM
> To: Ant Developers List
> Subject: RE: [WIP]Selectors

> >* assignProject() isn't really necessary.  If a selector needs
> to get hold
> >of the project, it can extend ProjectComponent, and the introspector will
> >take care handing it a project.  No point setting up parallel
> infrastructure
> >for doing this.
> Ok, I wasn't aware there was another mechanism. I'm a little concerned,
> though, since you can't extend from multiple base classes. If you
> need the
> project in a SelectorContainer, what do you do?
> I'd like to drop the method altogether, since I think it makes selectors
> far too aware of the environment they are running in. Ideally, they are
> encapsulated to just be classes that know how to pass or veto
> files without
> any knowledge of the context they are doing that in. Trouble is, I can
> imagine there being selectors that need to get at something elsewhere in
> the build, which is why I provided the method.
> Perhaps the need is rare enough that your solution is better, and anyone
> who needs a selector container with the Project can just reimplement
> SelectorContainer.

Drop it out of the interface, then at least the abstraction can be reused
elsewhere.  Some of the implementations will work outside Ant, and others

> >* Maybe add "throws BuildException" to isSelected().  How about we lose
> >checkForError() as well, and get isSelected() to assert that things are
> >good, throwing a BuildException if they're not.
> I really tried to stay away from throwing BuildExceptions here for the
> reason listed above, it breaks encapsulation by making selectors
> aware they
> are running in the context of an ant build.

BuildException is pretty general.  There's not really any reuse problems
there, except for maybe the name.  If you really don't want to throw
BuildExceptions, create a new exception type.

> >* Given the above, it might be worth making the interface completely
> >stateless, and pass the base directory in to isSelected(),
> rather than using
> >assignBasedir().
> Yes, if we go to one method only that is definitely the right answer.
> Although...
> One other feature I was thinking about adding is for the selector to keep
> track of the files it has selected and vetoed, along with a reset method
> for when it is being referenced in another fileset. That would give
> everything you get from FileScanner and then some. But it would
> also break
> the statelessness.

The interface doesn't have to be stateless.  If you do want to go with a
stateful interface, perhaps rather than adding a reset() method, change the
contract for assignBaseDir(), so that it is responsible for resetting state.

> >* The createBlah() methods should probably be addBlah() methods instead.
> Ok. Is there a reason to prefer one over the other? I've always
> used create
> because it gives more flexibility.

If you don't need that flexibility (and we don't here), then using an add
method gives future version of Ant a few more options, for example, to
automatically set references, or to use a subtype in place of the add
method's type.

> >NotSelector:
> >
> >* isSelected() probably should assert that there is exactly one nested
> >selector.  Otherwise you've got a nor selector, not a not selector.
> Is the issue that it isn't clear to people with multiple selectors in a
> <not> what the outcome would be, and that at times their
> intuition would be
> wrong?

Exactly.  Let's not give people the opportunity to get confused.  A <not>
selector that allows exactly one nested selector, has a very clear and
obvious behaviour.

> >FilenameSelector:
> >
> >* Do we really need 'negate'?  How about we take it out and wait
> to see if
> >it's useful.
> I went with Stefan's suggestion of putting it only where it is common.
> Since people use <exclude> an awful lot, I thought this a likely
> candidate.
> Perhaps not.

Or perhaps it is.  Leave it in if you like.


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

View raw message