[PATCH V2] wayland.xml: add "enum", "bitfield" and "is_bitfield" attributes
Nils Chr. Brause
nilschrbrause at gmail.com
Tue Sep 23 08:17:06 PDT 2014
On Tue, Sep 23, 2014 at 8:35 AM, Pekka Paalanen <ppaalanen at gmail.com> wrote:
> 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.
Originally, the idea to distinct between enumerations and bitfields was that
the user should be able to apply bitwise logic operations, where it might be
useful (everything I marked with is_bitfield="true") and not be able to do this
where this doesn't make sense (everywhere else).
Therefore, everything should fall in either of these categories. Either it makes
sense to use bitwise logic operations or it doesn't.
>> > 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
With the logic explained above, this would fall in my bitfield category. Having
more than the power-of-two values listed isn't a problem in my opinion. I see
these extra values as some sort of shortcuts for often used OR-combinations.
The strongly-typed part here only means that you can't compare
enums/bitfields of different type or pass type B, where type A is expected.
Therefore this can very well be done in a strongly typed language. As an
example have a look at my C++ bindings:
Especially at this part of the example:
>> > 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.
I understand, that the target audience of Wayland are high-level toolkits
and compositors, but I don't agree, that this is a good idea. If you only want
to create an EGL window and handle some input, there is no need for a huge
toolkit like Qt, in my opinion. A small binding library for the programming
language of your choice is much more useful and less wasteful in terms of
memory and performance.
>> > --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.
Probably not for C programmers, but it can very well be useful for C++
programmers. C++ has scoped enumerations since C++11, which turns
an enumeration into a distinct type. My C++ bindings are using this feature
for every enumeration that is not a bitfield.
> 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. :-)
In that case, I will have to maintain my own version of wayland.xml.
Since protocol changes are not happening on a daily basis, this should
be doable. ;-)
More information about the wayland-devel