2014-09-03 10:15 GMT+03:00 Pekka Paalanen <ppaala...@gmail.com>: > On Mon, 1 Sep 2014 22:07:44 +0200 > "Nils Chr. Brause" <nilschrbra...@gmail.com> wrote: > >> On Mon, Sep 1, 2014 at 10:45 AM, Pekka Paalanen <ppaala...@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.
It is, in the sense that it doesn't automatically cast int to enums, so that could break the API. Also, wouldn't it possibily be an ABI break? Afaik enums don't have a very defined size, so what is now a int32 could become e.g. a 16 bits enum field. -- Giulio > > 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 > _______________________________________________ > wayland-devel mailing list > wayland-devel@lists.freedesktop.org > http://lists.freedesktop.org/mailman/listinfo/wayland-devel _______________________________________________ wayland-devel mailing list wayland-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/wayland-devel