Missing methods on ChoiceType and TryType

[Guillaume Nodet]

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 ?

--
Cheers,
Guillaume Nodet
------------------------
Blog: http://gnodet.blogspot.com/

[jstrachan]

On 9/7/07, Guillaume Nodet <[hidden email]> 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/