On Wed, 27 Nov 2002, Conor MacNeill <[EMAIL PROTECTED]> wrote: > My definition of polymorphism in Ant is that I should be able to > extend a type and pass that new type to the task in place of the > original. [SNIP] The current approach is not that nice (defining a > type instance with id and then refid'ing it at point of use). > > So, this we should agree on as a desirable goal.
OK, +1 from me. > What comes next is the notation to express the use of derived type, > and the underlying implementation in the core. In Mutant I advocated > an explicit statement of the substitution This here? <http://cvs.apache.org/viewcvs.cgi/*checkout*/jakarta-ant/proposal/mutant/docs/Attic/features.html?rev=1.1#Extensibility> > My original Ant 1 patch (which Magesh has cited) used a different > approach where it tried to guess which underlying method is to be > used. So the example from the link above would become <copy todir="dest"> <classfileset dir="../../bin/ant1compat/"> <root classname="org.apache.tools.ant.Project"/> </classfileset> </copy> yes? Sorry, haven't had the time to read the patch to know. This one looks easier to write and read from a build file writer's perspective. What has been the reason to use a different notation in Mutant? > Using only one piece of information (the type name) has limits. I think I remember it. A problem arises when you have two different nested elements (element names) that both accept the same class. Say you have <mypath> that is derived from Path, what would it be used for in <javac ...> <mypath .../> </javac> src, classpath, sourcepath, bootclasspath and extdirs would be possible. Has this been the reason for your choice Conor? How would your patch deal with it Magesh? Stefan -- To unsubscribe, e-mail: <mailto:[EMAIL PROTECTED]> For additional commands, e-mail: <mailto:[EMAIL PROTECTED]>
