Referencing enums in other protocols

Pekka Paalanen ppaalanen at gmail.com
Wed May 2 08:11:01 UTC 2018


On Tue, 1 May 2018 10:18:08 +0000
Auke Booij <auke at tulcod.com> wrote:

> On Mon, Apr 23, 2018 at 9:08 AM, Pekka Paalanen <ppaalanen at gmail.com> wrote:

> > I think that's an oversight. It should indeed be possible to reference
> > enums just like interfaces from other protocol files.  
> 
> From my point of view, we did not add this when we were working on
> cross-referencing enums, in order to to keep the change as simple as
> possible and easy to understand. Now that (apparently) there is a use
> case, a solution would be welcome. But there are some problems to
> solve. How do you specify the right version of an enum in another
> file? What do you do if you want to refer to an enum in a protocol
> file that is not available? At what point DO we check that the
> cross-referenced enum exists? (Leaving it up to the protocol file
> writer to do correctly sounds prone to error.) Etcetera.

Enum versioning is a good question btw. that I never thought of, I guess.

For the availability, I would assume it should be fine to require the
depended-on protocol XML file to be present, if we choose the route of
providing depended-on XML files to scanners. One is going to need it
anyway for the code that is using the protocol.

OTOH, we already rely on protocol file writers to get the external
interface names correct as well. If we start using depended-on XML
files, we could check those names as well, or we can go with the
current situation and trust the writers.

Failing to spell the names correctly should eventually be pointed out
by the compiler: incompatible pointer casts in C for misspelled
interface names, and undeclared identifiers for misspelled enum values.
Even if the compiler doesn't find it, it will be apparent at runtime
testing the latest.

How far do we want to go to trigger the errors earlier than later?

The versioning question seems like a hard one.


Thanks,
pq
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 833 bytes
Desc: OpenPGP digital signature
URL: <https://lists.freedesktop.org/archives/wayland-devel/attachments/20180502/202f6874/attachment.sig>


More information about the wayland-devel mailing list