Re: Extending enums in IDL

Hi Stephan,

Stephan Bergmann píše v St 23. 11. 2016 v 12:51 +0100:

> > But you caught my interest now - so if I understand that correctly, it
> > is not a terrible breakage what's going on here: The client just gets an
> > unknown value; ie. the same thing as when we add a constant to the IDL,
> > and return this unknown new value - right?
>
> No, there are differences between (incompatibly) extending an UNOIDL 
> enum and (compatibly) extending a UNOIDL constants group; both technical 
> and contractual differences:
>
> The Java UNO runtime represents UNOIDL enum values as non-null 
> references to specific Java class instances (where those classes are 
> derived from com.sun.star.uno.Enum).  The bytecode generated for those 
> classes contains functions that map from enum integer values (as 
> obtained through the UNO bridges) to instances of those classes.  For 
> invalid values, that bytecode happens to return null references (it 
> could also throw exceptions, say).  So Java code confronted with an 
> extended UNOIDL enum will likely throw NullPointerExceptions and fail.

From the code I've read now, I see no indication that we would be
throwing NullPointerExceptions for the wrong values:

  ridljar/com/sun/star/uno/Enum.java

just happily returns whatever it was asked for:

    /**
     * Get the integer value of an enum value.
     * @return   the integer value.
     */
    public final int getValue() {
        return m_value;
    }

Adding new 'static final' members does not throw or return null or is
incompatible in any way here either - right?

Also

  com.sun.star.Blah.BlehEnum var = something(...);

where something() was extended in LibreOffice to return an additional
com.sun.star.Blah.BlehEnum's value should be fine, as the 3rd party
extension is supposed to use the jar's from LibreOffice it is running
against (ie. the new ones that contain the addition) - so all is
transparent there, right?

Or where exactly is the code that makes sure it throws, please?

> For client code that means:  When consuming such an integer value it 
> must be prepared to be presented with a value it does not know.  And 
> when producing such an integer value it must be prepared that any 
> consumer does not know the value.  Code written in such a way that it 
> does not support those requirements is broken.

Sure, but that's a completely different argument from my point of
view :-) - ie. semantic; not a language / technology limitation.

Considering that everybody introduces just constants and not enums in
the new code anyway (because of the 'extending enums is painful'
argument), I am proposing to open up the enums for additions for 5.3 as
a general (semantically) incompatible change, so that we don't have to
do the 'SomethingBlah2' dance every time we need to add stuff to an
enum.

[Unless there is really a technical limitation to doing that of course -
in that case code pointers / code examples would be much appreciated.]

I'll add this as an item to the ESC :-)

All the best,
Kendy