Re: Extending enums in IDL

On 11/23/2016 02:01 PM, Jan Holesovsky wrote:
> Stephan Bergmann píše v St 23. 11. 2016 v 12:51 +0100:
> > 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;
>     }

That's not the code I was talking about.  See handleEnumType 
(codemaker/source/javamaker/javatype.cxx) for the generated Java fromInt 
methods.

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

An extension will use the jars from the LO installation it is installed 
in.  A 3rd party app (esp. when run on a different machine) could use 
older jars.

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

What "code that makes sure it throws"?

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

Not sure what you want to say with that.  What /I/ wanted to say is, 
yes, exactly, there's a semantic difference between the non-extensible 
enum and extensible constant group/underlying integer approaches.  Chose 
the one that is supposed to fit your problem better.

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

First of all, not every concept is better modelled with a constant group 
than with an enum.  The choice needs thought, of course, and there's 
likely been various mis-choices across the API.

Second, enums just can't technically be extended compatibly in the same 
way that constant groups can be; see the Java fromInt issue above.

But whether we "have to do the 'SomethingBlah2' dance" is somewhat 
detached from those technical issues:  If we consider the pros of doing 
an incompatible change higher than the cons, we do such a change.