> From: Kuiper, Arnout <[EMAIL PROTECTED]> > > Nested objects > ============== > > Suppose the type is Foo. > 1. Check if Foo(String) exists. If so, use it, and we're done. > 2. Check if Foo(double) exists. If so, cast String to double, > use it, and we're done. > 3. iterate step 2 for each primitive type. > 4. Failure...
Random thought: Would a factory method instead of the constructor add value to your proposal? public static Foo create(String) We get the possibility of returning a subclass of Foo instead of Foo itself. However I cannot think of a situation right now, where I could use it. And the same effect could be achieved by using a strategie object. > - Nested elements are added with reflection. Look for a method > with the signature "void addObject(Type value)", where Object > is the name of the element. An object of type Type is instantiated, > and we recurse on that nested element. I think addFoo is better > than setFoo, because we can have multiple elements with the same tag. > In the following example, two include objects are added. If you named > the method setInclude, you might expect that only the last include is > known. This implies a subclass of a task cannot use a subclass of Type as Object? I like your proposal, but I am unsure, if this limitation makes reuse of tasks more difficult. Anyone? - tom
