Conor MacNeill wrote: > Costin Manolache wrote: >> >> The surprise would be why would a user (ab)use xmlns in such a construct >> :-) > > In the long run, IMOH, we want to have polymorphism - i.e. passing new > subtypes to a task or implementations of an interface. So, while today the > namespace doesn't make much sense (since the task defines what types it > will accept), in the future, it will be necessary. > > <path> > <foo:fileset dir="." /> > </path> > > This would be a reasonable construct (once we agree on the polymorphism > aspects) to pass a new type of fileset to an existing task. > > So, IMHO, namespaces should be considered at all levels, even if the first > pass may just be to cause an error.
What about postponing the polymorphism to Ant1.7 :-) - and let the ns settle down a bit ? I'm +1 on adding the ns parameter to IntrospectionUtil and even making it "pluggable". DynamicConfigurator will be a big problem ( you can't add methods to an interface without breaking binary compat - like JDK1.4 does in JDBC ). What will be the pattern for polymorphism ? Right now childs are created with a createFoo or addFoo. Somehow you need to associate ns:element with a method in the task. We can support a createFoo( String ns, String name ) - but that won't be polymorphism. Probably addFoo( Intf i ) and some mechanism to support creating classes that interface - but it sounds quite complex. Costin implement -- To unsubscribe, e-mail: <mailto:[EMAIL PROTECTED]> For additional commands, e-mail: <mailto:[EMAIL PROTECTED]>
