<div dir="ltr">On Mon, Sep 1, 2014 at 10:45 AM, Pekka Paalanen <<a href="mailto:ppaalanen@gmail.com" target="_blank">ppaalanen@gmail.com</a>> wrote:<br>><br>> On Sat, 30 Aug 2014 17:20:45 +0200<br>> "Nils Chr. Brause" <<a href="mailto:nilschrbrause@gmail.com" target="_blank">nilschrbrause@gmail.com</a>> wrote:<br>
><br>> > There are programming languages, that are more strongly typed than<br>> > C. People creating Wayland bindings for these languages probably want<br>> > to make use of this strong type system by declaring each enumeration a<br>
> > distict type.<br>> ><br>> > For code generation to work with these languages, there needs to be<br>> > information about which enumerations may be passed/received in which<br>> > request/event arguments.<br>
> ><br>> > This is accomplished by adding "enum" attributes to the "arg" elements<br>> > of requests and events. The values of these attributes have the format<br>> > "$interface.$enum", where "$interface" is the name of the interface,<br>
> > where the enumeration is declared and "$enum" is the name of the<br>> > enumeration, which is used in this argument.<br>> ><br>> > This might also be of documentary value.<br>><br>
> A nice idea, but did you check that all the things you tagged actually<br>> are enumerations and not bitfields?<br>><br>> Everything named "flags" is usually a bitfield, which means you can<br>> 'or' different enum values together to form new legal values that are<br>
> not listed in the enum. This will be a problem for languages which are<br>> strict with enums, and may even differentiate vs. bitfields.<div><br></div><div>My bad, I didn't consider bitfields. This would also require a separate</div>
<div>"bitfield" element for enums that are actually bitfields.</div><div><br></div><div>With some enums I'm not sure, whether they are enums:</div><div>- wl_pointer_button_state and wl_keyboard_key_state could as well be</div>
<div>one bit bitfields.</div><div>- wl_output_transform looks like an enumeration at first glance, but the</div><div>values 270, flipped_90, flipped_180 and flipped_270 can actually be</div><div>reconstructed by ORing the other values. So I guess it's a bitfield?</div>
<div><br>><br>> Another problem with this patch is that while it adds new syntax to the<br>
> protocol XML, it does not add anything that would either explain nor<br>> validate/enforce it. (We do not actually use the DTD for anything<br>> anymore.)<br>><br>> Yes, we do not have a document describing the XML format, and that is a<br>
> problem. Would be nice to start one, if anyone can work with Publican.<br>><br>> The very least, wayland-scanner should be reading the enum attribute<br>> and check that the referenced enum exists. I'm not sure if it can<br>
> generate a nice doc snippet into the generated code, but if there is a<br>> way to include that, it would be useful. We need *something* in the<br>> Wayland repository actually using these new attributes, so that they do<br>
> not bit-rot immediately.</div><div><br></div><div>I will look into the scanner code then. That is probably the easiest possibility</div><div>to prevent bit-rot, since I never did anything with Publican.</div><div><br>
</div><div>While I'm at that, I would also like to make use of the enum names in the</div><div>generated C code. As far as I can see, this would not break any existing</div><div>code, would it? Also, that would require the enum definitions to be at the top</div>
<div>of the header files (just below the struct forward declarations), because</div><div>enums cannot be forward declared. Would that be acceptable? </div><div><br>><br>> If you do this addition because of strictly types languages, you'll<br>
> probably also need the concept of "bitfield" in addition to "enum", and<br>> use it where appropriate.<br>><br>> I'd also like to punt this to the 1.7 development cycle, it is a bit<br>
> late for 1.6.</div><div><br></div><div>Yes, of course. :)</div><div><br>><br>><br>> Thanks,<br>> pq<br>><br><br></div></div>