On 9/7/07, Guillaume Nodet <[EMAIL PROTECTED]> wrote:
> The ChoiceType and TryType overrides lots of methods from
> ProcessorType so that the output (which is always this) can be of the
> current type, thus having a fluent DSL ;-)
> Unfortuntately, there are lots of methods missing on these classes.
> So we have one solution which is to make sure they are all overriden
> (with tall the maintenance burden).
> Another solution is to make the ProcessorType a generic:
>
> public abstract class ProcessorType<Type extends ProcessorType> {
> ...
> public Type to(String uri) {
> addOutput(new ToType(uri));
> return (Type) this;
> }
> ...
> }
>
> Then, the ChoiceType would become
>
> public class ChoiceType extends ProcessorType<ChoiceType> {
> ...
> }
>
> All the return type would be correct without the need to override them.
> However the drawback is that ProcessorType becomes a generic, so at
> some places, we need to write
> ProcessorType<?>
> like in the ProcessorType class:
> public abstract List<ProcessorType<?>> getOutputs();
> and in all classes that override this method.
>
> or force a type to specicy the generic used
> public class AggregatorType extends ExpressionNode<ProcessorType> {
>
> Is does not seems to affect the other modules in any way, so I'm keen
> on committing this patch. Opinions ?
So long as the build works; namely that the spring module works & the
generated XSD is fine, then please go right ahead. I'd been quite
reluctant to be too clever & do too much refactoring until I got the
XSD stuff sorted - now that works, feel free to refactor! (The code
could use some simplification)
--
James
-------
http://macstrac.blogspot.com/
