ant-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Tim Dawson" <>
Subject Re: [IDEA] Polymorphic types
Date Tue, 29 Jan 2002 20:12:25 GMT
I like the idea of polymorphic types, but I'm not sure about this type of implementation -
it requires that the type be a subclass of another type, and would prohibit interface implementation
from working. When I first ran into a similar issue a while back I got to thinking that what
would be a better approach would be to pair this issue with the whole deployment descriptor
issue, and have each type optionally declare a "property" that would be used to set it. (the
DD issue comes into play because the third declaration by necessity breaks the ability to
use the simple properties file to map the element name to the class)

By default, the property could be the type itself, e.g. <path>'s property would be "path",
<and> and <or>'s property would be "condition".

I have an implementation that I'm modifying now to serve as a proof of concept. Its from some
code I wrote last year (and currently in production) that uses a <element> to Class
mapping to parse XML into objects. Incidentally, my original code had the same problem Ant
does of assuming that the <element> was the same as the property name. Probably because
I got the idea for the code from looking at how Ant works, but was unable to extract something
generic that I could use.  :-)

I should (in between day-job and family commitments) be able to post this some time this week.

Does the general idea though, of actually registering the property name work for people? I
think it seems fairly obvious, especially when the default is to use the element name.


List:     ant-dev <?l=ant-dev&r=1&w=2>
Subject:  [IDEA] Polymorphic types <?t=100591829400008&r=1&w=2>
From:     Conor MacNeill <> <?a=100030834400001&r=1&w=2>
Date:     2001-11-16 13:50:01 <?l=ant-dev&r=1&w=2&b=200111>
[Download message RAW <?l=ant-dev&m=100591826612807&q=raw>]

Attached is a patch to the IntrospectionHelper to give a little 
ploymorphic behaviour for nested elements. I haven't committed this as I 
thought I'd get some reaction first.

Basically what this patch does is the following: When a nested creator 
cannot be found for a particular nested element, a check is done to see 
if the element corresponds to a datatype. If it does, a search is done 
for a superclass of the datatype for which the class does have an addXXX 
style creator.

In practice, this allows me to use derived types with core tasks without 
needing to change the core task. For example, if I wanted to use a 
classfileset type in a <copy> task, I do not need to change copy to add 
a addClassfileSet() method. I can just use this

     <copy todir="deptest">
       <classfileset dir="build/classes" 

Similarly, I can have classfilesets in jars without changing the <jar> 

It isn't perfect since some tasks use rolenames in their nested elements


For these tasks, the current method of refids needs to be used. 
Nevertheless, I think the patch is useful and makes it much more 
meaningful to define derived types.

The patch as it currently stands is just a proof of concept. There are 
some inefficiencies which can be factored out if required.

Let me know what you think?


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

View raw message