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

[Pekka Paalanen]

On Mon, 1 Sep 2014 22:07:44 +0200
"Nils Chr. Brause" <nilschrbrause at gmail.com> wrote:

> On Mon, Sep 1, 2014 at 10:45 AM, Pekka Paalanen <ppaalanen at gmail.com> wrote:

> > 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?

Perhaps, if it does not cause problems on C++. I'm not sure, but I
recall C++ being more strict than C wrt. enums.

I do not believe we can change the XML format so that some <enum>
elements would become <bitfield> instead. Existing generators would
probably ignore <bitfield> and we need to keep the XML format stable.

Considering all that, I'm not really sure that supporting strictly
typed languages is worth the effort. After all, this API is for toolkit
developers, and app developers will be using toolkit APIs, not this.


Thanks,
pq