Nested element polymorphism

[Dominique Devienne <DD...@lgc.com>]

Given an Ant (1.5.1) task which looks like below:

public static class SomeTask {

    public static class NestedType {
        public void setValue(String s) { ... }
    }

    public void addXyz(NestedType nt) {
        ...
    }
}

I'm extending it, like so:

public static class SomeTaskExt
                    extends SomeTask {

    public static class NestedTypeExt
                        extends SomeTask.NestedType {
        public void setMyNewAttr(Path p) {
            super.setValue(p.toString());
        }
    }

    public void addXyz(NestedTypeExt nt) {
        super.addXyz();
    }
}

My derived addXyz is never called, and I get an error saying NestedType
doesn't support the 'mynewattr' attribute!!! I then try:

public static class SomeTaskExt
                    extends SomeTask {

    public static class NestedTypeExt
                        extends SomeTask.NestedType {
        public void setMyNewAttr(Path p) {
            super.setValue(p.toString());
        }
    }

    public NestedType createXyz() {
        return new NestedTypeExt();
    }
}

But same impass! I see IntrospectionHelper simply does a put of all
NestedCreator it find for a given nested element name, the last one always
overriding the previous NestedCreator registered for the same name... For
some reason, it appears in my case that the base class'
SomeTask#addYz(NestedType) always gets selected as *the* creator for that
particular nested element name.

This lack of prioritization between the various creator methods
(add/addConfigured/create), although documented, prevents any kind of
polymorphic extension of nested elements (which are not necessarily
DataTypes) when using either add/addConfigured. The createXyz allows
polymorphism (it's a kind of factory method in fact), but since its not used
preferentially compared to the add flavors, it can't be used (and when both
are there, should the addXyz be called, being passed the derived type
created?).

Furthermore, in presence of overloading of the add methods, looks like the
last one in to the Hashtable wins, and thus depends on the ordering of
Class.getMethods() (if it's specified at all in the Java spec).

Basically, I'm stuck by this, and since I was trying to hack around Ant
1.5.1 (as opposed to modifying Ant CVS) to do some proof of concept
(<propertyset> specifically, and enabling <java><sysproperty pathref="pref"
/></java>) that I could use right away, this is not good (<propertyset>
works in my <junitx> and <javax> pseudo-tasks extending <junit>/<java>, not
<sysproperty pathref="pref" /> for the issue related above).

I'm sure I'll be told by some I should modify Ant source code in HEAD, but
being able to use *right now* these extensions in Ant 1.5.1 is a must for
me. 

Unlike Jon Skeet who wants clarification on the code in IH, I'd like us to
specify precisely the protocol to select a nested creator for a given nested
element, which would be extension and polymorphism friendly.

Thanks all for your thoughts on this, and good weekend. --DD

--
To unsubscribe, e-mail:   <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>

Re: Nested element polymorphism

[Nick Chalko <ni...@chalko.com>]

Dominique Devienne wrote:

>I'm sure I'll be told by some I should modify Ant source code in HEAD, but
>being able to use *right now* these extensions in Ant 1.5.1 is a must for
>me. 
>  
>
Checkout the 1.5.1 branch, and make the changes, will enable you to use 
it Right Now.
Then submit the patch and everyone will benifit.  
:-P
Or perhaps someone will know a workaround.
:-D

-- 
Nick Chalko                                         Show me the code.
                          Centipede
  Ant + autodownloadable build plugins + needed jars autodownload.
              http://krysalis.org/centipede
---------------------------------------------------------------------



--
To unsubscribe, e-mail:   <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>