Le 2015-10-02 14:12, Auke Booij a écrit :
However, I'm not sure who you are trying to protect here. Everyone
agrees that the new attributes should not change anything for C/C++,
and in the current patches, they don't. And the other bindings writers
understand the compatibility issues regarding this change, and, if I
may speak for the majority of them, care much less about compatibility
issues than about being able to provide proper APIs for their users.
In haskell, and many other modern languages, an easily fixable compile
issue (we keep calling it a compatibility issue, which I think is a
misnomer, although I don't know what category it should fall under) is
*vastly* preferred over a potential bug. Arguably, that's the entire
point of the language. Modern languages attempt to cross-check as many
properties as possible, and the enum attribute would contribute
greatly to this, even if that means breaking API every so often.
The wayland protocol currently does not specify the enum attribute,
and I see no way how to write an API whose entire purpose is to
*break* when you erroneously mix up enum attribute data, without
breaking API as this data is added. More importantly, this problem
does not matter because it is not a problem but a *solution*.
I mostly agree with that, from my Rust point of view.
While a huge part of my bindings can be generated by the scanner, these
is still a need of some hand-written glue, to cleanly connect Rust into
the wayland-client lib via the protocol. And given the current package
model of Rust, I expect each protocol file to be interfaced as a rust
package including a given version of the xml file and using the scanner
to generate it at compile time. With all these packages (the scanner
being one of them) properly versioned, nobody would be take by surprise
by and update of the protocol file.
So, my main argument for Rust is that the mental overhead of binding
generation would not be handled by the downstream consumer, but by the
bindings maintainers. If some protocol requires an old version of the
scanner, so be it, it just needs to set its dependencies accordingly and
everything will be fine.
These were my two cents about Rust, I cannot talk for other languages.
Victor
_______________________________________________
wayland-devel mailing list
wayland-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/wayland-devel
