Le 2015-10-05 21:53, Nils Chr. Brause a écrit :
Bill Spitzak wrote:
Similarly it seems like an "open" indicator that can be added to enums
(including bitfields) would help, as it sounds like some languages
make it
difficult or cryptic to allow casting of arbitrary numbers to the enum
value.
The "open" flag > would be an indication that the language binding
needs to
support this. The lack of it does *not* mean that a language binding
must
prevent casting of arbitrary numbers to the enum.
Since a language binding should support unknown values anyway, I don't
quite
see the benefit of an 'open' flag.
It depends. In some case, it could be valid to support unknown values by
simply ignoring them.
Consider a program written against a certain version of the protocol.
Then, it is used on a compositor with a newer version of the protocol,
where one of the enums have one more possible value.
What can the client do if it receives this value ? It has no possible
way to give it a proper meaning, so it can either ignore it, or trigger
a fatal error. Are there other options ?
In this case, for a "closed" enum, the binding can decide to ignore any
value received on the wire that is not described in the XML, as anyway,
the client would not know what to do with it (and if they knew, they
should be using a more recent version of the binding).
This can be useful in some languages to allow such a thing. For example
in Rust, handling an "open" enum would require some overhead in terms of
usability of the API, to gracefully handle unknown values. While simply
ignoring them would lead to a much simpler design. Unless it is not a
good idea to ignore unkown values, in which case I'd gladly read an
explanation of why it is and which problems I missed.
Without this flag, I have to choices: either consider enums as
uints/ints and a set of constants to compare against (like C), of put
this overhead on every single enum. To be honest, none of these
possibilities feel satisfying. But They are still possible outcomes,
hence the bindings _can_ live without this indication.
There is a similar concern with the enum/bitfield duality: in Rust, enum
type are just a set of possible values, and are not meant for bitwise
operations. On the other hand there is way to define bitfiealds types,
with all the fancy methods you like to have to manipulate bitfields. So
having the information of which enum is a bitfield would allow me to
make the generated API much more comfortable to use.
I hope this was a clear explanation of why I think these values can be
useful. Without then, I cannot really make use of the new attribute
linking an argument to its enum, apart from writing it in the
documentation and using (u)ints everywhere.
_______________________________________________
wayland-devel mailing list
wayland-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/wayland-devel
