Enums, bitfields and wl_arrays

[Bryce Harrington]

On Tue, Oct 13, 2015 at 08:27:58PM +0100, Auke Booij wrote:
> On 13 October 2015 at 16:19, Solerman Kaplon <solerman at gmail.com> wrote:
> > Em 13-10-2015 11:35, Nils Chr. Brause escreveu:
> >>
> >> In C++ the order doesn't matter either, since each entry has a defined
> >> value. I wonder why this is different in Java?
> >
> >
> > Java Enums doesn't have "value". It just a class instance. But since it's a
> > class one can add regular fields to it, like this (writing of the top of my
> > head):
> >
> > public static enum Orientation {
> >   Portrait(1), Landscape(2);
> >
> >   final int value;
> >
> >   Orientation(int value) {
> >     this.value = value;
> >   }
> >
> >   public int getValue() {
> >     return this.value;
> >   }
> > }
> >
> > Solerman
> 
> 
> I really don't understand this discussion. Is the claim that the usage
> of enums in java is problematic, because inserting a new value in an
> existing enum might change the index of later values, thereby creating
> an inconsistency?
> 
> If so, all I can say that clearly the object you want to associate
> with wayland-style enums is not whatever Java has invented for an
> "enum". The values that are associated to names inside wayland enums
> are very clear-defined, and if a language cannot safely couple names
> back to values, then that is a language that does not understand the
> concept of a variable. If this is a fundamental problem about Java
> enums, you better find a way around it, but I don't see how this is in
> any way a problem on the wayland side: there are enums, and enums
> contain names, and those names have values.

I got the impression based on the prior discussion that there were
already several ideas for working around this in java.  So perhaps it
can be just an internal implementation detail of that binding.

> 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?

Bryce