Enums, bitfields and wl_arrays

[Auke Booij]

On 15 October 2015 at 09:18, Erik De Rijcke <derijcke.erik at gmail.com> wrote:
> If wayland enums would not explicitly declare values, you'd have the same
> problem in C. However since wayland enums do explicitly declare their value,
> *and* because C allows you to override an enum 'internal value', you don't
> have that problem here. Unfortunately, Sun in all it's infinite wisdom
> decided that Java enum 'internal values' can not be overridden. Only new
> 'properties' can be attached.
>
>>
>> But if this is indeed the issue you are discussing, then this must
>> have already been a problem before the introduction of additional XML
>> attributes.
>
>
> Correct. My current Java bindings create a Java enum with the wayland enum
> value as an additional property. If the order would change, that would be a
> potentially breaking change.
>
>> Can we agree on the following? Until there is any firm specification
>> of open/closed enums, every enum should be considered open, and
>> although some legal values might be listed, others might not be, and
>> some might only be legal sometimes.
>
>
> Ok for me but it would be very nice to have the open/closed information ;)
>
>>
>> New values may be added (but not
>> changed or removed) to protocol specifications without introducing any
>> compatibility issues.
>
>
> This is not clear for me. Compatibility issues for the current C bindings or
> for all language bindings? If it's for all language bindings than this might
> introduce a whole explosion of derived implicit specifications for each
> language. Eg. the enum order in Java. Better would be to specify a goal "no
> compatibility issues" and a set of form specifications eg. "the order of an
> enum shall not be changed".

This is exactly the kind of specification that I do not intend to
make, since it is (ostensibly) caused solely by a broken
implementation of enums in Java. It's not a problem in C, and not a
problem in any language that understands the concept of a variable.

On 13 October 2015 at 23:15, Bryce Harrington <bryce at osg.samsung.com> wrote:
> On Tue, Oct 13, 2015 at 08:27:58PM +0100, Auke Booij wrote:
>> But if this is indeed the issue you are discussing, then this must
>> have already been a problem before the introduction of additional XML
>> attributes.
>>
>> Can we agree on the following? Until there is any firm specification
>> of open/closed enums, every enum should be considered open, and
>> although some legal values might be listed, others might not be, and
>> some might only be legal sometimes. New values may be added (but not
>> changed or removed) to protocol specifications without introducing any
>> compatibility issues.
>
> So, worst case if the binding language is inflexible here, then it'd
> need to maintain a mapping for the values to resequence them?

Yes, that is my point exactly.