Let's turn around your question: Tell me of a (string) role (beside the special task/type cases) that would not be an interface? What good a bean is, if it's not of an expected Java type? What method or field are you going to use/call on it?
I agree with Costin, all tasks/types become simply beans. You should be able to use any one of these beans in any place it's suitable to use it, i.e. any time the Java type/role requested is part of the bean's type (in the isAssigneableFrom() sense). The type being requested depends on who requests it. Inside or outside targets, it's any bean. And I mean really any bean: Doesn't need to implement anything Ant-related. This is implicitly what we call today a datatype, and they can be id'd. The subset of these beans that also have an execute method are also implicitly tasks. The different subsets of these beans that implements FileSelector are suitable to use within filesets, and tasks deriving from MatchingTask since we're talking about it. I fail to see what is wrong with this scenario. --DD -----Original Message----- From: Stefan Bodewig [mailto:[EMAIL PROTECTED] Sent: Wednesday, April 23, 2003 11:12 AM To: [EMAIL PROTECTED] Subject: Re: antlib On Wed, 23 Apr 2003, Dominique Devienne <[EMAIL PROTECTED]> wrote: > Forcing roles to map to an interface is probably a *good* idea! Maybe, hmm, probably, not convinced ... > Every single bean would become implicitly a data-type, and the ones > with an execute() method implicitly become tasks. Beyond that, all > other roles are interfaces. How would you have a task that also is a condition? It implements Condition and has an execute method? [DD] Yes! What's wrong with that? How would you have a datatype that also is a condition? This may be far-fetched, not sure. Stefan
