[PATCH wayland] Add "enum" attribute to "arg" elements

[Nils Chr. Brause]

On Mon, Sep 1, 2014 at 10:45 AM, Pekka Paalanen <ppaalanen at gmail.com> wrote:
>
> On Sat, 30 Aug 2014 17:20:45 +0200
> "Nils Chr. Brause" <nilschrbrause at gmail.com> wrote:
>
> > There are programming languages, that are more strongly typed than
> > C. People creating Wayland bindings for these languages probably want
> > to make use of this strong type system by declaring each enumeration a
> > distict type.
> >
> > For code generation to work with these languages, there needs to be
> > information about which enumerations may be passed/received in which
> > request/event arguments.
> >
> > This is accomplished by adding "enum" attributes to the "arg" elements
> > of requests and events. The values of these attributes have the format
> > "$interface.$enum", where "$interface" is the name of the interface,
> > where the enumeration is declared and "$enum" is the name of the
> > enumeration, which is used in this argument.
> >
> > This might also be of documentary value.
>
> A nice idea, but did you check that all the things you tagged actually
> are enumerations and not bitfields?
>
> Everything named "flags" is usually a bitfield, which means you can
> 'or' different enum values together to form new legal values that are
> not listed in the enum. This will be a problem for languages which are
> strict with enums, and may even differentiate vs. bitfields.

My bad, I didn't consider bitfields. This would also require a separate
"bitfield" element for enums that are actually bitfields.

With some enums I'm not sure, whether they are enums:
- wl_pointer_button_state and wl_keyboard_key_state could as well be
one bit bitfields.
- wl_output_transform looks like an enumeration at first glance, but the
values 270, flipped_90, flipped_180 and flipped_270 can actually be
reconstructed by ORing the other values. So I guess it's a bitfield?

>
> Another problem with this patch is that while it adds new syntax to the
> protocol XML, it does not add anything that would either explain nor
> validate/enforce it. (We do not actually use the DTD for anything
> anymore.)
>
> Yes, we do not have a document describing the XML format, and that is a
> problem. Would be nice to start one, if anyone can work with Publican.
>
> The very least, wayland-scanner should be reading the enum attribute
> and check that the referenced enum exists. I'm not sure if it can
> generate a nice doc snippet into the generated code, but if there is a
> way to include that, it would be useful. We need *something* in the
> Wayland repository actually using these new attributes, so that they do
> not bit-rot immediately.

I will look into the scanner code then. That is probably the easiest
possibility
to prevent bit-rot, since I never did anything with Publican.

While I'm at that, I would also like to make use of the enum names in the
generated C code. As far as I can see, this would not break any existing
code, would it? Also, that would require the enum definitions to be at the
top
of the header files (just below the struct forward declarations), because
enums cannot be forward declared. Would that be acceptable?

>
> If you do this addition because of strictly types languages, you'll
> probably also need the concept of "bitfield" in addition to "enum", and
> use it where appropriate.
>
> I'd also like to punt this to the 1.7 development cycle, it is a bit
> late for 1.6.

Yes, of course. :)

>
>
> Thanks,
> pq
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.freedesktop.org/archives/wayland-devel/attachments/20140901/d09200d3/attachment.html>