Enums, bitfields and wl_arrays

[Pekka Paalanen]

On Fri, 02 Oct 2015 14:43:57 +0200
Victor Berger <victor.berger at m4x.org> wrote:

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

I'm trying to protect *you* from people who write the XML files. But if
you say you do not need this kind of protection, and no other non-C
language bindings writer needs either, then we can simply proceed in
the way you wrote your patch set:

These new attributes are defined to be for documentation purposes only,
and we explicitly say that you should *not* use this information in
generating APIs. If you do so anyway, you have no right to complain if
your or a third person's code breaks.

This affects you and all your language's users. If they ever complain to
Wayland upstream about breaking things, we'll just laugh at their face
and point to the spec that says your generator is buggy to begin
with. ;-)

Well maybe not so rudely.

I want to be sure that you fully understand the implications here,
before we commit to this rule.

And it's not just you, it's everyone wanting to write a bindings
generator, e.g. for Java and C++.

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

This is a very good point. I understand you are covered, then.

I see Auke just posted another interesting email.

So we have thumbs up from Haskell and Rust for not needing any
additional XML stability guaranteed than what C does.

Did we have Java and C++ people around? Other languages?


Thanks,
pq
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 811 bytes
Desc: OpenPGP digital signature
URL: <http://lists.freedesktop.org/archives/wayland-devel/attachments/20151002/f009dc71/attachment-0001.sig>