Re: [xsd-users] no abstract base classes with "Customizing the generated type — the complex case"

[Oliver Schneider]

Hi Boris

> Yes, exactly. The "base" in type customization means something to base
> your implementation on, not necessarily base class as in inheritance.
> You could, for example, use the generated implementation as a data member
> in your custom implementation.
Gotcha, but this will be very messy and break the polymorphism. But
there are probably lots of non-polymorphism cases where this is useful.

> I am still not clear what problem we are trying to solve here. The
> generated "base" implementations for customized types are not used
> directly anywhere in the generated code. I also don't see how anyone
> can easily mix the "base" implementation for a custom one -- after
> all the base implementation normally has a special name format (for
> example, the '_base' suffix). If you wanted to, you could make it
> even clearer: '_base_implementation_do_not_use_directly' ;-).
> 
> Is it maybe forgetting to implement _clone() that's the problem?

now we're getting somewhere! (i think we were talking about different
things before :D)

I am implementing _clone in the *_impl classes. Having it also
implemented in the *_base classes requires the *_base classes to be
instanciable (aka not abstract). Since I want to make "print" pure
virtual in "person_impl", and i can only override "print" in the
superman_impl and batman_impl classes, the superman_base and batman_base
classes are abstract (as they don't override "print").
Thus superman_base and batman_base cannot be instanciated in the _clone
function.

So, in addition to your previous fix, and to keep the possibility of
adding the *_base type as a member instead of a base in the
non-polymorphic case, could you either add a command-line argument to
prevent the creation of _clone (manually for every _base class would be
fine), or automatically not create it for polymorphic _base classes?

/Oliver