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

Tue Sep 23 14:19:26 PDT 2014

On Tue, Sep 23, 2014 at 8:17 AM, Nils Chr. Brause <nilschrbrause at gmail.com>
wrote:

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

In this case, what is the point of making the distinction?  Why not just
specify everything as a bitfield?  What do you gain from knowing that two
things will never be ORed together?

>
> >> >
> >> > 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:
> https://github.com/NilsBrause/waylandpp
> Especially at this part of the example:
> https://github.com/NilsBrause/waylandpp/blob/master/example/test.cpp#L194
>
> >> > 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. ;-)
>

In any case, that's probably not a huge deal.  It doesn't change often and
should usually be mergable.

>
> >
> >
> > Thanks,
> > pq
>
> Cheers,
> Nils
>

On Tue, Sep 23, 2014 at 8:17 AM, Nils Chr. Brause <nilschrbrause at gmail.com>
wrote:

> 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:
> https://github.com/NilsBrause/waylandpp
> Especially at this part of the example:
> https://github.com/NilsBrause/waylandpp/blob/master/example/test.cpp#L194
>
> >> > 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. ;-)
>
> >
> >
> > Thanks,
> > pq
>
> Cheers,
> Nils
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.freedesktop.org/archives/wayland-devel/attachments/20140923/24947256/attachment-0001.html>