You are viewing a plain text version of this content. The canonical link for it is here.

Posted to dev@ant.apache.org by Magesh Umasankar <um...@apache.org> on 2002/11/26 21:54:32 UTC

[PATCH] Adding Dynamic elements for the n'th time

Hi,

This is basically a modification of Conor's patch
to enhance the Introspection capabilities. See:

http://marc.theaimsgroup.com/?l=ant-dev&m=100591826612807&w=2

The difference is that my patch looks for methods whose
parameter class type is assignable from the nested element's
class type.

Let us say we have the following mappings:
TagDefA->ClassA
TagDefB->ClassB

ClassA implements Interface1
ClassB implements Interface1

Currently, if we want these as nested elements, 
we would have to define

addTagDefA(ClassA)
addTagDefB(ClassB)

With this patch, if you define, 

addInterface1(Interface1)

it would be good enough and will be called when
you have a nested element like <tagdefa .../> or 
<tagdefb.../> and no equivalent addTagDef methods.

So, Where does this apply?  It applies to
<condition>, <filterchain>, etc. and of course the
<fileset> issue that Conor originally solved.

In my patch, I have minimally shown how this
is applied to ConditionBase.

This patch depends upon my earlier patch Project.java
because when Condition is initialized, it expects
its nested elements to have been already initialized.
If they are not, then it balks.

Cheers,
Magesh

Re: [PATCH] Adding Dynamic elements for the n'th time

Posted by Magesh Umasankar <um...@apache.org>.

----- Original Message -----
From: "Conor MacNeill" <co...@cortexebusiness.com.au>


> I think, perhaps, we should agree that polymorphic behaviour is a
desirable
> objective. I certainly think it is. When I define a subclass of a type I
> should not need to change all tasks that take that type.

+1

> Conor

Cheers,
Magesh


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

Re: [PATCH] Adding Dynamic elements for the n'th time

Posted by Costin Manolache <cm...@yahoo.com>.

Magesh Umasankar wrote:

> ----- Original Message -----
> From: "Conor MacNeill" <co...@cortexebusiness.com.au>
> 
>> 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. I
>> haven't studied Magesh's patch in detail but for fully flexibly
>> polymorphism, you need to identify the type of the object being passed
>> and the method on the task to which you will pass it (i.e. two
>> independent things). Using only
> one
>> piece of information (the type name) has limits.
> 
> Yes.  If the method name to be used is also to be dynamic,
> we can make that happen as well - but, I think, going forward
> with baby steps will be easier.  If I start packing more and
> more into a single patch, the chances of its inner workings
> being debated in detail gets slimmer ;-)

As I said, I'm +1 on the original patch - I see it as an improvement
that can be further improved :-)

You know me - if something doesn't have a clear solution I usually
propose a hook :-)

We already have a number of hooks on element configuration, maybe the
way to go would be to extend those.

I have a use case: have introspection recognize ${dyn:properties} that
evaluate to objects, and call the right method ( instead of 
object->string->object conversion ). Another use case would be a more 
pluggable mechanism for the "property editors" ( the convertors between 
strings and real params ).

JMX introduces another set of use cases - if we want to support
JMX tasks using a task adapter, we'll need to use MBeanInfo and 
setAttribute to configure it. 

IMO it may be a good idea to find the best "extension points" and 
add hooks in the right place, and then play with different options
( some will be added to core, some may stay outside ).

Costin

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