[xsd-users] Groups and AttributeGroups

[Mark Watson]

Hi Boris,

It wasn't object code size that I was concerned about. Rather the size of
the generated code and thus the difficulty in browsing/understanding that.
You could reasonably say that I should never need to look at the generated
code, since I should know how to manipulate the objects from the mapping
rules, and so the issue will go away as I become more familiar with those
mapping rules.

Anyway, you answered my question and I could agree that the
behind-the-scenes complexity you describe may not be justified for the
resulting simplifications in the generated interface.

Best regards,

Mark


On 3/12/07 12:31 PM, "Boris Kolpackov" <boris at codesynthesis.com> wrote:

> Hi Mark,
> 
> Mark Watson <mark at digitalfountain.com> writes:
> 
>> Returning to this question. I have the templates approach working. However,
>> I have some 20-30 attributes/elements defined in 7 or 8 groups which then
>> appear in various combinations in 10 or so different types and the result is
>> hundreds and hundreds of lines of generated code. The templates approach
>> works, but it feels a little unmanageable at this scale.
> 
> What exactly are you concerned here with? Is it the object code size
> that results from the generated code? Is it the object code size
> that results from the function templates? Note that, in this case,
> it does not make much sense to count the lines of generated code
> because all the generated accessors/modifiers (pretty much what
> constitutes a group in the generate code) are inline one-liners.
> 
> 
>> What's the chance that some mechanism to factor out groups into common
>> base classes might make it into some future xsd release ?
> 
> I am not convinced it is a good idea. The only benefit I see is
> the ability to handle group generically without using things
> like templates. There are a number of serious disadvantages
> though, including significant complications in the generated
> code logic and increased object code size.
> 
> To be specific, right now each element/attribute in a type
> results in the following three major parts in the generated
> code:
> 
>  (1) Inline accessors/modifiers.
> 
>  (2) A small piece of code in the c-tor.
> 
>  (3) A small piece of code in the parsing function.
> 
> These are generated in every class that references a group. With
> the base class approach we will need exactly the same code in the
> common base class plus the following in each class that references
> the group:
> 
>  (1) A small piece of code that forwards arguments to the base c-tor.
> 
>  (2) A significantly more complicated parsing code that figures
>      our when and what to delegate to the group classes.
> 
> 
> I think (1) here and (2) above will be about the same. I expect
> (2) to result in more code than (3) above. Plus you get all the
> extra (2) and (3) above for each group class.
> 
> 
> hth,
> -boris