[Xcb] parametrized structs

[Ran Benita]

On Fri, Aug 22, 2014 at 12:01:27PM +0200, Christian Linhart wrote:
> On 08/22/14 09:53, Ran Benita wrote:
> > On Mon, Aug 18, 2014 at 04:41:23PM +0200, Christian Linhart wrote:
> >> +Parametrized structs
> > 
> > What does this mean?
> > 
> This is something similar to C++ templates ( but a bit simpler... )
> ( I'll provide an alternative further below )
> 
> Here's why we need that:
> 
> The struct DeviceTimeCoord contains a list whose length is determined
> from outside: It is determined by the member "num_axes" in the
> GetDeviceMotionEvents-reply.
> 
> So we need a mechanism to get that length into the struct.

Right, I see the problem.

> For me it is not clear what will be better:
> * explicit parametrization like in the first example?
> * implicit parametrization by inlining as in the second example?

A third option might be to add a sort of "dynamic scoping", e.g.

    <struct name="DeviceTimeCoord">
        <field type="TIMESTAMP" name="time" />
        <list type="DeviceTimeCoord" name="axisvalues">
            <fieldref inherit>num_axes</fieldref>
        </list>
    </struct>

where "<fieldref inherit>" (or another better name) means: if you can't
find the field in the immediate parent, look at its parent, etc.
But this seems error-prone and probably not any easier to implement.

> My guess is that explicit parametrization will be easier to implement in the generator.

c_client.py in these parts is quite a mess, so it's hard to tell really.

> Implicit parametrization by inlining will make writing the xml easier
> when such a struct is only needed at one place.
>
> When it is needed in multiple places, then inlining will cause
> code-duplication whereas explicit parametrization will
> allow code-reuse.
> 
> ***
> 
> What do you think?

I'm not sure. The "paramref" approach looks complicated, really
stretching the format. On the other hand the inlining approach has its
own set of problems: duplication in multiple places and namespacing in
this case, how the API looks, etc.

Keep in mind that we don't really need to be flexible for future
extensions. I really don't think we'll see any more extensions with
complex encodings like xkb or xinput, and hopefully new extensions will
be written with an XCB xml or at least with XCB in mind. So we can
limit ourselves to the simplest solution which fits only the existing
requirements.

In order to make a wise decision then, I think you should consider if
there are any other cases where such a construct is needed (in
xinput/xkb)? If so, do any of them have a "parameterized" struct which
appears in more than one place (unlike DeviceTimeCoord)?

> Chris
> 
> P.S.: I can implement either of the two schemes in the generator
> though I have a slight preference for 
> explicit parametrization because it allows
> code-reuse on the xml-side.

As I said, lets first see if such reuse is needed (but in the end of
course you should implement what you think is best).

> Here's why I feel confident that I can implement that:
> I have a lot of experience will parsing and code-generation,
> especially from former projects and a job where I wrote
> parsers for CASE-tools and IDEs. The most complex one was a parser
> parsing C++-code, where I implemented to whole ISO C++-98 standard
> including template instantiation...

A parser for C++, that's heroic :)

Ran