[xsd-users] RE: xsd bypasses customized types

[Richard Cresswell]

Boris,

Our base customized object is derived from a string, but is
implemented as another type in our customized code.  The problem is
that once we derive an object from the custom base, it creates that
derived object with the string constructors.  Instead, we want it to
see that it is derived from a custom object and create a from-base
constructor:

DerivedObject::DerivedObject(BaseObject)

This way all of the custom BaseObject constructors can be used for the
DerivedObject.

Does that make more sense?

Thank you,

Richard

On Tue, Apr 20, 2010 at 10:52 AM, Boris Kolpackov
<boris at codesynthesis.com> wrote:
> Hi Richard,
>
> Richard Cresswell <rcresswell at gmail.com> writes:
>
>> Boris, that fixed the xsd tree generation, but the generated code
>> still does not compile.  It creates a default constructor of form:
>>
>> DerivedObject::
>> DerivedObject ()
>> : ::base::BaseObject ()
>> {
>> }
>>
>> Shouldn't it detect that DerivedObject is derived from the custom type
>> and create the correct constructors?
>
> I assume by "correct constructors" you mean that your custom
> implementation of BaseObject class does not define a default
> constructor. Unfortunately, the only way to detect this would
> be to parse (as in C++) your BaseObject definition and figure
> out which constructors it defines.
>
> The way XSD handles this is that it expects the custom
> implementation to have the same interface as the generated
> version would have had. I don't see any other practical
> way, unfortunately.
>
>
>> Applying the patch also broke tests/cxx/tree/name-clash/inheritance.
>> Could this be because of other missed patches?
>
> I am not sure what's the reason for this. In the current code
> base all tests pass.
>
>
>> cc.set ("cxx-tree-name-processor-stem-set", NameSet ());
>> cc.set ("cxx-tree-name-processor-member-set", NameSet ());
>>
>> was still
>>
>> c.context ().set ("cxx-tree-name-processor-stem-set", stem_set);
>> c.context ().set ("cxx-tree-name-processor-member-set", member_set);
>
> The two code fragments are semantically equivalent in this case.
>
>
>> I am concerned that my codebase diverges too much from where you are
>> with 3.3, but I am reluctant to upgrade to the 3.3 beta since I will
>> need to patch again when you do the final release.  Do you have an ETA
>> for when the official 3.3 will go out?
>
> It should be out later this week or early next week.
>
> Boris
>