peter reilly wrote: > On Wednesday 30 April 2003 17:54, Costin Manolache wrote: >> Stefan Bodewig wrote: >> > On Tue, 29 Apr 2003, peter reilly <[EMAIL PROTECTED]> wrote: >> >> We are still left the problem of the Type create<Name>() pattern. >> > >> > I don't think that it was solvable. Almost any soltion world require >> > cooperation of the classes implementing the create method. >> > >> > What we can do is adapting all core classes that use the createPattern >> > to also provide the add pattern (with modifications along the lines >> > you suggest) - and make IntrospectionHelper favor addXYZ over >> > createXYZ just as it setXYZ(SomeType) over setXYZ(String) now. >> >> Can you explain again what's wrong with create ? I think I missed it... > > The problem is that create returns an object created by the class. Thus > the use-as attribute would not be able to substitute a different object. > The solution is to get for example Javac to implement a new addClasspath() > method, with (minor) mods in the ant framework to allow path objects to be > created by the framework.
But what does "create" has to do with the polymorphism ? All the discussions so far were about adding an addSomething() - while leaving all existing use cases unmodified. I could see a problem with the existing add methods. Costin > >> >> My understanding was that whatever is in use today will continue to work >> the same, we just add a new pattern at the end. > Exactly. > > Peter
