On Tue, Sep 23, 2014 at 8:17 AM, Nils Chr. Brause <nilschrbra...@gmail.com> wrote:
> On Tue, Sep 23, 2014 at 8:35 AM, Pekka Paalanen <ppaala...@gmail.com> > wrote: > > On Tue, 23 Sep 2014 13:59:39 +0800 > > Boyan Ding <stu_...@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 <nilschrbra...@gmail.com> wrote: > On Tue, Sep 23, 2014 at 8:35 AM, Pekka Paalanen <ppaala...@gmail.com> > wrote: > > On Tue, 23 Sep 2014 13:59:39 +0800 > > Boyan Ding <stu_...@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 >
_______________________________________________ wayland-devel mailing list wayland-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/wayland-devel
