<div dir="ltr"><div><div><div>> (yes the language binding could prevent this, but programmers writing<br>
> direct Wayland api are already wading into dangerous waters and can<br>
> probably be trusted to do this correctly. So for now I don't think there<br>
> is any need for a strict control).<br><br></div>I do not quite agree with this. Yes, they should know they are wading into dangerous waters, but any error that can be prevented, should be. It also helps of course, for features like code completion, although as I am writing Rust bindings, that doesn't apply to me. <br><br>
> Maybe it could be added, ie you can make global enumerations as well as<br>
> local enumerations. Local ones are still useful for the error values.<br><br></div>That would be a good solution, but maybe that's making the specification a bit too complex? I would be in favour of moving everything to same namespace as the interface, but of course, compatibility issues will arise with exciting binding generators.<br><br></div>In any case, I think the specification should be as strict as possible, because making it stricter is hard, but making it less strict is easy. <br>
</div><br><div class="gmail_quote">On Thu, 23 Apr 2015 at 20:59 Bill Spitzak <<a href="mailto:spitzak@gmail.com">spitzak@gmail.com</a>> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><br>
<br>
On 04/23/2015 11:28 AM, Jeroen Bollen wrote:<br>
>  > Using enum="interfacename.enumname" would probably work. The<br>
>  > "interfacename." is optional if you are describing a method on the same<br>
>  > interface. Another possibility is to just add interface="interfacename"<br>
>  > to the argument along with enum="enumname".<br>
><br>
> The second possibility wouldn't work for bitfields that take enums from<br>
> different interfaces.<br>
<br>
I didn't think that would be allowed. The bitmap arg can only or<br>
together a set of values from a single enumeration.<br>
<br>
>  > An even more drastic approach would be to put all the values in the same<br>
>  > namespace as interfaces, again renaming (or perhaps changing the values)<br>
>  > as necessary. This would allow the programmer to write<br>
>  > Widget.setAlignment(Left). It would also match how enums in C work.<br>
><br>
> Putting enums next to interfaces, instead of inside of them, to me, also<br>
> seems like the best option. I don't think it'll get any support however,<br>
> as it isn't backwards compatible.<br>
<br>
Maybe it could be added, ie you can make global enumerations as well as<br>
local enumerations. Local ones are still useful for the error values.<br>
Some sort of aliasing could be used to migrate other local enumerations<br>
to global without breaking any existing code.<br>
</blockquote></div>