[Xcb] parametrized structs

[Ran Benita]

On Mon, Aug 25, 2014 at 01:21:57PM +0200, Christian Linhart wrote:
> This can be further simplified by making the <typearg>-tag optional if 
> the parameter has the same name as the field of the fieldref-expression
> used as the arg, like it is the case here.
> This will then look as follows:
> ===============================================================================
> 01    <struct name="DeviceTimeCoord">
> 02        <field type="TIMESTAMP" name="time" />
> 03        <list type="INT32" name="valuators">
> 04            <paramref type="CARD8">num_axes</paramref>
> 05        </list>
> 06    </struct>
> 07
> 08    <request name="GetDeviceMotionEvents" opcode="10">
> 09        <field type="TIMESTAMP" name="start" />
> 10        <field type="TIMESTAMP" name="stop" altenum="Time" />
> 11        <field type="CARD8"     name="device_id" />
> 12        <pad bytes="3"/>
> 13        <reply>
> 14            <field type="CARD8"  name="xi_reply_type" />
> 15            <field type="CARD32" name="num_events" />
> 16            <field type="CARD8"  name="num_axes" />
> 17            <field type="CARD8"  name="device_mode" enum="ValuatorMode" />
> 18            <pad bytes="18" />
> 19            <list type="DeviceTimeCoord" name="events">
> 20                <fieldref>num_events</fieldref>
> 21            </list>
> 22        </reply>
> 23    </request>
> ===============================================================================
> 
> So, the only difference to your idea of dynamic scoping (besides naming of the tag)
> is that the <paramref>-tag gets a type-attribute. ( line 4 ).
> 
> With that scheme we have a simple xml-scheme and still the full flexibility
> of the original paramref-approach.
> 
> What do you think about that new proposal?

I don't know how much effort it will take to implement, so I'll only
consider the semantics now. Maybe something simple and unambigous like
the following?

    A fieldref is resolved in the context of its containing type.

    A paramref is like a fieldref, only it is resolved in the context
    which *refers* to its containing type.

In this case, the containing type is DeviceTimeCoord, and the context
which refers to the containing type is the GetDeviceMotionEvents reply.

Is this close to what you had in mind? I'll have to think whether that's
sound and sufficiently flexible but it feels right to me now.

> As far as I remember from my XKB-review, XKB will not need 
> parametrized structs, but I can be wrong on that.
> ( I will organize and post the XKB-patches sometime later, 
> after we'll have finished the XInput stuff. )

I haven't ran into something that needed them either. So that's good.

> >> 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 :)
> Yeah, it was a special kind of project, details omitted here. ;-)
> But it was ultimately successful after stretching the deadlines as much as possible...

Good to hear :)

Ran