On Wednesday 30 April 2003 16:24, Stefan Bodewig wrote: > On Tue, 29 Apr 2003, peter reilly <[EMAIL PROTECTED]> wrote: > >> it is, with an addXYZ(Condition) method marking it up - I'm not > >> really fond of any of the proposed naming conventions so far. > > > > Whats wrong with add(Condition) ? > > Nothing so far.
The only problem I can think of is that it clashes with Collection.add(Object) and thus the problem is that classes may implement it "by accident". I my implementation (bugzilla 19446), I use the signature nestedElement(Class), but I would be happy with anything. > > >> We still need a solution for the ambiguos cases, though. > > > > 1.7+ ? > > Which makes things even more difficult to explain. > > "You can use <zipfileset> everywhere where <fileset> is documented, > except for task that happen to also have another nested element that > is implemented by FileSet such as ......" This is not quite true. The add() method has to be explicly implemented by the class author, thus the documentation of the class (task/datatype/ nested element) would have to document this fact (i.e. what if any typed nested elements are allowed). The magic attribute is more general and is not implemented by the class author. Thus it needs to be documented along those lines. - for example the elements that use paths would not currently work. > > We shouldn't rush 1.6 but get it right now. > True, but we should let the search for a perfect solution stop a good solution ;-) My implementation provides (I think) a good solution to the "how do we have a new condition/filter or selector without changing core ant code" problem. The use of add() should be restricted (by the class authors's choice) to container like objects - I think that polymorphism is a separate problem, and use of the magic implementation attribute is a good solution to it. Peter
