[PATCH V2] wayland.xml: add "enum", "bitfield" and "is_bitfield" attributes

[Pekka Paalanen]

On Tue, 23 Sep 2014 13:59:39 +0800
Boyan Ding <stu_dby at 126.com> wrote:

> On Mon, 2014-09-22 at 11:27 -0700, Jason Ekstrand wrote:
> 
> > I'm a little unsure.  I think trying to completely solve this problem
> > in a way that will truly make strongly typed languages happy is
> > insanity.  That said, I'm cautiously ok with defining bitfields and
> > enums as long as we are very careful in scoping what "bitfield" and
> > "enum" mean.  A "bitfield" should have only power of two values and
> > the result should always be interpreted as an OR of those values.  An
> > enum should have every possible value enumerated.  If anyone has a
> > good example of something that validly doesn't fit into either of
> > these, please speak up.
> > 
> > The example of wl_output.transform is an enum because every
> > possibility is enumerated.  From C or a similar language, you can do
> > fun stuff like "if (transform & WL_OUTPUT_TRANSFORM_FLIPPED)" to
> > determine if there is a flip.  In a strongly typed language, you can't
> > do this and we shouldn't bend over backwards to make it possible.  If
> > we try and come up with some convoluted system that makes this
> > possible with typed languages, we're going to cause far more pain than
> > it's worth.
> > 
> > 
> > One other thing that we need to keep in mind here is the primary
> > target audience of Wayland and its libraries.  That audience is
> > compositors and toolkits.  Most of those are written in C and C++.
> > What we don't want to do is to do a bunch of things for the sake of 1%
> > of the target audience that makes the rest have to bend over
> > backwards.  When I said "cautiously OK", I mean that I don't see that
> > happening yet and I don't see a valid use for an enum that doesn't
> > follow one of those two rules.  However, if we have a plausible case
> > where doing so would make everyone's lives easier, I'm going to not be
> > a big fan.
> > 
> > 
> > Please note that I'm not trying to insult Haskel or other functional
> > or strongly typed languages or the people who use them.  I'm simply
> > trying to be pragmatic and recognize that people who want to write an
> > app in haskel that manually bangs the Wayland protocol isn't the
> > target audience.
> > 
> > 
> > --Jason
> 
> Completely agree with Jason here.
> 
> Actually the present "enum" are just mnemotic to 32-bit int or uint
> values (and that's why the type field in current protocol is "int" or
> "uint" instead of things like "enum"). Though developers of
> strongly-typed languages may not like it, it is versatile and makes
> sense. Any attempt to define what an "enum" or "bitfield" is will change
> the current semantics and introduce a lot of complexity. There may exist
> a way to make it work perfectly (and I'm okay with it if it really
> exists), but I doubt whether the effort worth it since it doesn't do any
> good to C or C++ wayland programmers, who are the main targeted audience
> of wayland.

Yes, I agree. I think we have a concensus here. While it might be nice
for certain languages, they are not the intended audience. Of course it
doesn't mean that you should not create Wayland protocol bindings in
those languages, but it just means that we at upstream are not willing
to spend effort on making it convienient or proper all the way and
ensuring it does not cause problems. Particularly as it does not seem
obvious what would be the correct solution now and in the future, and
the impact of the benefit looks very small in this specific case.

Sorry Nils, I believe we are not going to take this. :-)


Thanks,
pq