[xsd-users] Re: Polymorphism enhancements.

[Bill Pringlemeir]

On  9 Jan 2009, boris at codesynthesis.com wrote:

> Thanks for the feedback. My comments are below.

>>> We can always add an option (e.g., --generate-explicit) for this but
>>> I am wondering how useful it will be.
>>
>> That is a killer if you have 'operator' functionality in a wrapper
>> with parameter overloading.  You end up getting ambiguous definitions.
>> For example,
>>
>> <xs:complexType name="quaterino">
>> <xs:sequence>
>> <xs:element name="oridinal" type="int_t"/>
>> </xs:sequence>
>> <xs:attribute name="i" type="int_t" default="0"/>
>> <xs:attribute name="j" type="int_t" default="0"/>
>> <xs:attribute name="k" type="int_t" default="0"/>
>> </xs:complexType>
>>
>> class  quaterino: public quaterino_base
>> {
>> public:
>> operator int();
>> }
>> quaterino operator+(const quaterino &, const quaterino&);
>> quaterino operator+(const quaterino &, const quaterino&);
>> quaterino operator+(const quaterino &, const quaterino&);
>
> I am not sure I follow. Which definitions are ambiguous? Why do
> you have three identical declarations of operator+ for quaterino?

Sorry, I edited that email several times.  I didn't compile it ;-) I
was going to show the need to write,

 quaterino operator+(const quaterino &, int);
 quaterino operator+(int &, const quaterino&);

If we don't have the conversion operator... but that is actually the
int constructor that XSD generates.  The need for the conversion
function was to ful-fill other legacy requirements.  I can not easily
modify the other classes.

The explicit conversion can be painful if you also wish to define
conversion operators.  Ie, 'operator int()'.  This often leads to
ambigious function calls as the compiler can pick multiple ways to
match overloaded functions.  You probably don't have many people doing
this and they can just use the '--custom-type class=' syntax.

> We are also planning to change the way we handle default values. Right
> now we parse the string representation of the default value as it appears 
> in XML Schema at runtime. So for:

> <attribute name="foo" type="int" default="123"/>

> We generate something like:

> int foo_default_value_ = traits<int>::parse ("123");

> We are planning to change this to perform parsing at compile-time
> so that we will generate:

> int foo_default_value_ = 123;

> For XML Schema types that are mapped to fundamental C++ types, such as
> int, double, etc., we will probably eliminate the variable altogether
> and return the literal directly. I think that will help your case.

Sounds much better than the idea I had.

> One idea that we have is to allow you to specify which hierarchies
> in your object model actually need polymorphism. Normally a schema
> would contain only a handful of types (usually derived from one or
> two bases) that should be polymorphism-aware (that is, they can be
> used in substitution groups and/or xsi:type). We can detect these 
> types when substitution groups are involved but with xsi:type any
> type can theoretically be used.

> So we can provide an option, something like --polymorphic-base,
> where you can specify root types for polymorphic hierarchies in
> your schemas. Then the XSD compiler will generate polymorphism
> support code (and c-tors with auto_ptr arguments) only for these
> types and types that are derived from them. I believe this will
> result in significant object code size reduction for most schemas.

> What do you think?

That is an excellent idea.  I can see that someone might wish to have
derived xsi:string values.  However, the majority of people will just
use one string type.  Having auto_ptr variants of strings is not
useful 99% of the time.  It just generates extra code.

I was lead to believe that the auto_ptr variants were to ease
construction of composites.  Ie, you build base complex types and use
the auto_ptr variants to build up the higher level aggregate.  This by
itself is not really a good reason to do this.  However, the use with
polymorphism that you noted is.  XSD must be using _clone and the
auto_ptr variant to make this work in 'setXxxx'?  That isn't obvious
to a user of the tools.

Would it be possible to detect the substition group to have this added
automatically to the polymorphic type list?  Hmmm.  Actually that
seems difficult as XSD has no idea that the base class is going to be
extended.  The abstract keyword is a very good clue for this though.

Thanks again,
Bill Pringlemeir.

-- 
Someday we'll look back on all this and plow into a parked car.