<div dir="ltr"> <div class="gmail_extra"> <div class="gmail_quote">On Tue, Sep 23, 2014 at 8:17 AM, Nils Chr. Brause <<a href="mailto:nilschrbrause@gmail.com" target="_blank">nilschrbrause@gmail.com</a>> wrote: <blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">On Tue, Sep 23, 2014 at 8:35 AM, Pekka Paalanen <<a href="mailto:ppaalanen@gmail.com">ppaalanen@gmail.com</a>> wrote: > On Tue, 23 Sep 2014 13:59:39 +0800 > Boyan Ding <<a href="mailto:stu_dby@126.com">stu_dby@126.com</a>> 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. </blockquote><div> 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? </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"> >> > >> > 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: <a href="https://github.com/NilsBrause/waylandpp" target="_blank">https://github.com/NilsBrause/waylandpp</a> Especially at this part of the example: <a href="https://github.com/NilsBrause/waylandpp/blob/master/example/test.cpp#L194" target="_blank">https://github.com/NilsBrause/waylandpp/blob/master/example/test.cpp#L194</a> >> > 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. ;-) </blockquote><div> </div><div>In any case, that's probably not a huge deal. It doesn't change often and should usually be mergable. </div><div> </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"> > > > Thanks, > pq Cheers, Nils </blockquote></div> </div></div><div class="gmail_extra"> <div class="gmail_quote">On Tue, Sep 23, 2014 at 8:17 AM, Nils Chr. Brause <<a href="mailto:nilschrbrause@gmail.com" target="_blank">nilschrbrause@gmail.com</a>> wrote: <blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">On Tue, Sep 23, 2014 at 8:35 AM, Pekka Paalanen <<a href="mailto:ppaalanen@gmail.com">ppaalanen@gmail.com</a>> wrote: > On Tue, 23 Sep 2014 13:59:39 +0800 > Boyan Ding <<a href="mailto:stu_dby@126.com">stu_dby@126.com</a>> 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: <a href="https://github.com/NilsBrause/waylandpp" target="_blank">https://github.com/NilsBrause/waylandpp</a> Especially at this part of the example: <a href="https://github.com/NilsBrause/waylandpp/blob/master/example/test.cpp#L194" target="_blank">https://github.com/NilsBrause/waylandpp/blob/master/example/test.cpp#L194</a> >> > 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 </blockquote></div> </div>