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 Wed, 30 Jan 2002 03:50:27 GMT
Sorry I wasn't as clear as I could have been.

Imagine the following antlib deployment descriptor:

  <typedef element="and"
  <typedef element="or"
  <taskdef element="echo"

if a build file was encountered that had

<target name="foo">
   <condition property="isMacOsButNotMacOsX">
      <os family="mac" />
        <os family="unix" />

The implementation of the Condition task and the Condition types (And, Os,
Not, etc) would have been much simpler. Instead of all the addAnd() addOs()
addNot() etc. methods, there would have been one addCondition() method in
the ConditionTask class and one addCondition() method in the ConditionType
abstract superclass (which would no longer need to inherit through the task

This result is the same as what Conor proposed, the difference in what I'm
proposing is how you determine what add() method to call -- something more
well-defined, like the suggested deployment descriptor, or guessing based on
introspecting superclasses (& eventually implemented interfaces), which is
more flexible but less deterministic?


> -----Original Message-----
> From: Jose Alberto Fernandez []
> Sent: Tuesday, January 29, 2002 5:02 PM
> To: Ant Developers List
> Subject: Re: [IDEA] Polymorphic types
> Can you give an example of your proposal?
> I really do not understand how it works.
> Jose Alberto
> ----- Original Message -----
> From: "Tim Dawson" <>
> To: <>
> Sent: Tuesday, January 29, 2002 8:12 PM
> Subject: Re: [IDEA] Polymorphic types
> 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.
> Tim
> 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"
> baseclass="build/classes/org/apache/tools/ant/Main.class"/>
>      </copy>
> Similarly, I can have classfilesets in jars without changing
> the <jar>
> task.
> It isn't perfect since some tasks use rolenames in their
> nested elements
> <blah>
>      <fromfileset>
>      <tofileset>
> </blah>
> 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?
> Conor
> --
> To unsubscribe, e-mail:
> <>
> For additional commands, e-mail:
> <>
> --
> To unsubscribe, e-mail:
> <>
> For additional commands, e-mail:
> <>

Do You Yahoo!?
Get your free address at

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

View raw message