[xsd-users] Re: Polymorphism enhancements. [was: Polymorphic
problems.]
Boris Kolpackov
boris at codesynthesis.com
Fri Dec 5 03:43:25 EST 2008
Hi Bill,
Bill Pringlemeir <bpringle at sympatico.ca> writes:
> 1. I have had some problems with constructors with a single arguement.
> This will be used as conversion values by the compiler. This is
> especially problematic with simpleType extentions. However, I have
> found that customizing the simpleType with '--custom-type foo' was
> often necessary, so I get the chance to use explicit in the
> wrapper. Users always have the option to do this.
I am not sure adding explicit to all single-argument c-tors is a
good idea. Consider, for example, this fairly common situation:
<simpleType name="int_t">
<restriction base="int"/>
</simpleType>
<xs:complexType name="type">
<xs:sequence>
<xs:element name="i" type="int_t"/>
</xs:sequence>
</xs:complexType>
Right now one can write:
type t (10);
If we add explicit, then one will need to write:
type t (int_t (10));
We can always add an option (e.g., --generate-explicit) for this but
I am wondering how useful it will be.
> 2. In the polymorphism example, if person complex type and the
> reference element are declared with 'abstract="true"', the same
> code is generated no matter what. It would be nice if the person
> base had a pure virtual destructor and the type-factory-map.txx
> supported base objects that cann't be created. I believe that this
> is possible as in instance documents we would have a different tag
> name or xs:type attribute. This allows a way to specify ABC in
> schema notation, which seems to be the intent of 'abtract'. This
> would be most helpful in preventing mistakes where an ABC is
> serialized.
Yes, we can do this. I've added it to the TODO list.
> 3. It is possible that a schema will have many similar data types with
> the same defaults. Would it be possible to use the same default
> static instance in generated code. Ie, if we have 20 "xs:int
> default='0'" attributes, then twenty static elements are created.
Do you mean the same private value (in order to save space) or the
same public accessors for these values?
> 4. Consider the schma below. Processing with XSD defaults creates
> only one constructor. Add '--generate-base-ctor' and we have two.
> Use '--generate-polymorphic' and we have *four* constructors. This
> is due to the auto_ptr interface needed by 'e3'. Also, these
> constructors are fairly expensive as the constructors set many of
> the attributes to defaults. Attributes are better (from a code
> generation perspective) than elements because optional/default does
> not require constructor arguments (passing all the values creates
> more code). Couldn't xsd generate a private 'setDefaults()' for
> the derived class and call this within the body?
Yes, this is already on our TODO list. We plan to analyze the overhead
and see if adding a common init() function will help.
> Alternatively, more control over the 'auto_ptr' mechanism that allows
> selective generation of constructors would help.
Not sure how this can be done. Specifying a set of c-tors to generate
for each type sounds too burdensome.
Thanks for all the suggestions!
Boris
More information about the xsd-users
mailing list