On Wed, 27 Nov 2002, Conor MacNeill <[EMAIL PROTECTED]> wrote:
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>
Yes.
Let me say at this juncture that Mutant is and will remain dead. I'm on an evolutionary tack now. Nevertheless there are some ideas I was able to explore and some refactorings which can be applied to Ant1 without breaking things.
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.
Yes, this is correct.
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?
As you state below it is when the same type is used in multiple set/add methods that the above breaks down. Also the XSI based file would be able to be validated by a schema aware parser, I think (hope), whereas the above cannot be validated (which may not be a big deal, although some seem to like having the ability to do so.)
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?
Yes
Conor
-- To unsubscribe, e-mail: <mailto:[EMAIL PROTECTED]> For additional commands, e-mail: <mailto:[EMAIL PROTECTED]>
