Dominique Devienne wrote: >>Interesting... So how come DynamicTag is not compatible with >>Ant 1.6, when it compiles and works fine with 1.5.1??? Sounds >>like an incompatible API change to me, which hopefully will be fixed. It compiles on Ant 1.6, but currently the unknownelement returned does not get resolved. (!). In a previous cvs build, a null pointer exception gets thrown as the target had not been set on the unknown element.
>>2) DynamicTag is lazy, thanks to UnknownElement. Your rewrite is >>creating >>the element at parse-time, my implementation does it only at runtime. >>Again, >>I favor delaying the instantiation and configuration. Ant should never >>have >>mingled parsing of the XML and instantiation of the model in the first >>place. I am not sure this is correct, the task/datatype will be stored as an unknown element until the target containing the task/datatype is run. I however find the treatment of "id", which is done at parse time, a bit scary. >>5) Your point #4 is the new feature over DynamicTag as I understand it. I'm >>not too sure it's better syntactically than explicitly having >>(composing) >>several nested elements, each being a dynamic tag of a different type. True, This is quite correct. The ability may however be useful for some tasks. >>Your >>rewrite does add new reflection 'rules', making stuff happen >>auto-magically >>thru reflection. I'm not saying it's bad, I'm pointing out it adds some, >>when DynamicTag doesn't. True, I must admit this is a bit cheeky! >>Something that I wish Ant added was the notion of 'role', to partition >>the >> task/type namespace. There is on-going work on antlib (ant/proposal/sandbox/antlib) which does something on those lines. Cheers. Peter
