> From: Kuiper, Arnout <Arnout.Kuiper@nl.origin-it.com>
>
> 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
|