Re: [interface-announce] info/CWS calc51 : New constants com::sun::star::sheet::FilterOperator2

[Frank Schoenheit, Sun Microsystems Germany]

Hi Thomas,

> *Description*
> -------------
> The com::sun::star::sheet::FilterOperator2 constants extend the
> com::sun::star::sheet::FilterOperator enum

Since we recently reached an agreement that incompatible UNO API changes
are not bad by definition (but only if done improperly), wouldn't this
be a good chance to stress this new freedom, and extend the
FilterOperator enum, instead of this somewhat strange construct of
extending the /enum/ with a /constants group/ FilterOperator2?

Ciao
Frank

--
- Frank Schönheit, Software Engineer          frank.schoenheit@... -
- Sun Microsystems                       http://www.sun.com/staroffice -
- OpenOffice.org Base                        http://dba.openoffice.org -
- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -  -
- Sitz der Gesellschaft:                                               -
- Sun Microsystems GmbH, Sonnenallee 1, D-85551 Kirchheim-Heimstetten  -
- Amtsgericht München: HRB 161028                                      -
- Geschäftsführer: Thomas Schröder, Wolfgang Engels, Wolf Frenkel      -
- Vorsitzender des Aufsichtsrates: Martin Häring                       -
- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -  -

---------------------------------------------------------------------
To unsubscribe, e-mail: interface-discuss-unsubscribe@...
For additional commands, e-mail: interface-discuss-help@...

[thomas.benisch]

I discussed this issue some time ago with our UNO experts.
The result was that extending an UNO enum is unacceptable.

Thomas

---------------------------------------------------------------------
To unsubscribe, e-mail: interface-discuss-unsubscribe@...
For additional commands, e-mail: interface-discuss-help@...

[Mathias Bauer]

Frank Schönheit - Sun Microsystems Germany wrote:

> Hi Thomas,
>
>> *Description*
>> -------------
>> The com::sun::star::sheet::FilterOperator2 constants extend the
>> com::sun::star::sheet::FilterOperator enum
>
> Since we recently reached an agreement that incompatible UNO API changes
> are not bad by definition (but only if done improperly), wouldn't this
> be a good chance to stress this new freedom, and extend the
> FilterOperator enum, instead of this somewhat strange construct of
> extending the /enum/ with a /constants group/ FilterOperator2?

To my knowledge we still didn't agree on doing incompatible changes
before 4.0.

BTW: while changing enums currently is impossible without getting bitten
by our API compatibility watch dog, IIRC it tolerates extensions of
constant groups. Please correct me if I'm wrong. But in practice,
constant groups and enums are equally prone to compatibility problems.
If code is confronted with an unknown constant - in the firm belief that
this can't happen as it wasn't specified at the time when the code was
written - bad things can happen.

Wouldn't it make sense to specify that constant groups are extensible
per se, so that each code dealing with them must be able to handle
unknown values? Perhaps with giving hints or specifying how unknown
values of a particular group should be treated?

So constant groups could be changed at any time with good confidence,
without considering this to be "incompatible". Without this explicit
declaration adding constants to groups actually is incompatible, though
we didn't AFAIK consider it to be so when we already added numerous
constants to several groups.

Regards,
Mathias

--
Mathias Bauer (mba) - Project Lead OpenOffice.org Writer
OpenOffice.org Engineering at Sun: http://blogs.sun.com/GullFOSS
Please don't reply to "nospamformba@...".
I use it for the OOo lists and only rarely read other mails sent to it.


---------------------------------------------------------------------
To unsubscribe, e-mail: interface-discuss-unsubscribe@...
For additional commands, e-mail: interface-discuss-help@...

[Frank Schoenheit, Sun Microsystems Germany]

Hi Thomas,

> I discussed this issue some time ago with our UNO experts.
> The result was that extending an UNO enum is unacceptable.

Ah ...

For what reasons? Just curious whether those reasons still hold now that
we said incompatible API changes are allowed, if done carefully.

Ciao
Frank

--
- Frank Schönheit, Software Engineer         frank.schoenheit@... -
- Sun Microsystems                      http://www.sun.com/staroffice -
- OpenOffice.org Base                       http://dba.openoffice.org -
- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -

---------------------------------------------------------------------
To unsubscribe, e-mail: interface-discuss-unsubscribe@...
For additional commands, e-mail: interface-discuss-help@...

[Frank Schoenheit, Sun Microsystems Germany]

Hi Mathias,

> To my knowledge we still didn't agree on doing incompatible changes
> before 4.0.

Right, we only agreed to disagree :)

In the concrete case, I think replacing the enum with an (extensible)
constant group is better than introducing the FilterOperator2, which
just adds clutter to the API.

We would need to explicitly check this, but in my understanding the only
language binding where this is (compile-time) incompatible is C++. In
Java, it should be compile-time compatible, and perhaps even
runtime-compatible. All other language bindings should be completely
agnostic of such a change.

Well, Stephan could probably point out some esoteric cases where this
breaks ... Glad^Wsad he's on vacation currently :)

> BTW: while changing enums currently is impossible without getting bitten
> by our API compatibility watch dog, IIRC it tolerates extensions of
> constant groups. Please correct me if I'm wrong.

You aren't, to my knowledge.

> Wouldn't it make sense to specify that constant groups are extensible
> per se, so that each code dealing with them must be able to handle
> unknown values? Perhaps with giving hints or specifying how unknown
> values of a particular group should be treated?

Yes, would be a reasonable general guideline. Not sure we have a place
for such guidelines, though.

> So constant groups could be changed at any time with good confidence,
> without considering this to be "incompatible". Without this explicit
> declaration adding constants to groups actually is incompatible, though
> we didn't AFAIK consider it to be so when we already added numerous
> constants to several groups.

Does our watch dog bite when adding new constants to a *published*
group? Never tried. Adding new constants to an unpublished group has
never been a problem, by definition and in theory, since they were
allowed to be changed incompatibly.

Ciao
Frank

--
- Frank Schönheit, Software Engineer         frank.schoenheit@... -
- Sun Microsystems                      http://www.sun.com/staroffice -
- OpenOffice.org Base                       http://dba.openoffice.org -
- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -

---------------------------------------------------------------------
To unsubscribe, e-mail: interface-discuss-unsubscribe@...
For additional commands, e-mail: interface-discuss-help@...

[Niklas Nebel]

On 06/18/09 10:40, Frank Schönheit - Sun Microsystems Germany wrote:
> In the concrete case, I think replacing the enum with an (extensible)
> constant group is better than introducing the FilterOperator2, which
> just adds clutter to the API.

The FilterOperator2 constants group contains the old and new operators,
the TableFilterField2 struct contains an integer instead of the
FilterOperator enum, and the XSheetFilterDescriptor2 interface can be
used instead of XSheetFilterDescriptor.

So, "replacing the enum with an constant group" is exactly what was
done, keeping the old types for compatibility.

Niklas

---------------------------------------------------------------------
To unsubscribe, e-mail: interface-discuss-unsubscribe@...
For additional commands, e-mail: interface-discuss-help@...

[Frank Schoenheit, Sun Microsystems Germany]

Hi Niklas,

>> In the concrete case, I think replacing the enum with an (extensible)
>> constant group is better than introducing the FilterOperator2, which
>> just adds clutter to the API.
>
> The FilterOperator2 constants group contains the old and new operators,
> the TableFilterField2 struct contains an integer instead of the
> FilterOperator enum, and the XSheetFilterDescriptor2 interface can be
> used instead of XSheetFilterDescriptor.
>
> So, "replacing the enum with an constant group" is exactly what was
> done, keeping the old types for compatibility.

okay, my wording might not have been precise enough, "keeping the
replaced item" is not my definition of "replace", but of "add" :)

I explicitly suggest to sacrifice compatibility, and gain a cleaner API.
Having a FilterOperator2, and the respective changes in all interfaces
and implementations which in/directly use it, is ugly, to say at least.

Ciao
Frank

--
- Frank Schönheit, Software Engineer         frank.schoenheit@... -
- Sun Microsystems                      http://www.sun.com/staroffice -
- OpenOffice.org Base                       http://dba.openoffice.org -
- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -

---------------------------------------------------------------------
To unsubscribe, e-mail: interface-discuss-unsubscribe@...
For additional commands, e-mail: interface-discuss-help@...

[Mathias Bauer]

Frank Schönheit - Sun Microsystems Germany wrote:

>> So constant groups could be changed at any time with good confidence,
>> without considering this to be "incompatible". Without this explicit
>> declaration adding constants to groups actually is incompatible, though
>> we didn't AFAIK consider it to be so when we already added numerous
>> constants to several groups.
>
> Does our watch dog bite when adding new constants to a *published*
> group? Never tried. Adding new constants to an unpublished group has
> never been a problem, by definition and in theory, since they were
> allowed to be changed incompatibly.

Yes, even published constant groups were allowed to be changed, but IMHO
the problems caused by that (or not caused by that) are the same as in
case of enums. We treated them differently, though there is no technical
reason. No language binding today would have a technical problem with an
extended enum as none of them really does boundary checks and breaks if
a "new" enum value is found (even C++). OTOH we can't exclude that any
future language binding might do that, but that is true for constant
groups also.

To avoid uncertainties I thought it might be a good idea to make it
clear that constant groups may be extended without considering that an
incompatible change and that all language bindings (and API users) must
take that into account, while enum changes are always seen as incompatible.

Strictly speaking, wanting to change an enum is a clear sign that this
type never should have been an enum in the first place. The
recommendation always was that the enum type should be used only for
enumerations that can be seen as fixed if only probable or forseeable
changes of the world around us are considered. Thus weekdays, month
names etc. are good candidates as odds are high that they don't change
in the life time of our API. ;-) Many enums in our API are wrong, it
seems that enum or constant group was chosen at random (e.g. in the
toolkit API).

Regards,
Mathias

--
Mathias Bauer (mba) - Project Lead OpenOffice.org Writer
OpenOffice.org Engineering at Sun: http://blogs.sun.com/GullFOSS
Please don't reply to "nospamformba@...".
I use it for the OOo lists and only rarely read other mails sent to it.


---------------------------------------------------------------------
To unsubscribe, e-mail: interface-discuss-unsubscribe@...
For additional commands, e-mail: interface-discuss-help@...

[Frank Schoenheit, Sun Microsystems Germany]

Hi Mathias,

> Yes, even published constant groups were allowed to be changed,

didn't know that ....

> but IMHO
> the problems caused by that (or not caused by that) are the same as in
> case of enums. We treated them differently, though there is no technical
> reason. No language binding today would have a technical problem with an
> extended enum as none of them really does boundary checks and breaks if
> a "new" enum value is found (even C++).

In the C++ language binding, a "Foo_MAKE_FIXED_SIZE = SAL_MAX_ENUM" is
generated for a enum type Foo. IIRC, this was introduced a few years
ago, because of anticipated or real problems with the enum size ...

Ciao
Frank

--
- Frank Schönheit, Software Engineer         frank.schoenheit@... -
- Sun Microsystems                      http://www.sun.com/staroffice -
- OpenOffice.org Base                       http://dba.openoffice.org -
- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -

---------------------------------------------------------------------
To unsubscribe, e-mail: interface-discuss-unsubscribe@...
For additional commands, e-mail: interface-discuss-help@...

[Mathias Bauer]

Frank Schönheit - Sun Microsystems Germany wrote:

> Hi Mathias,
>
>> Yes, even published constant groups were allowed to be changed,
>
> didn't know that ....
>
>> but IMHO
>> the problems caused by that (or not caused by that) are the same as in
>> case of enums. We treated them differently, though there is no technical
>> reason. No language binding today would have a technical problem with an
>> extended enum as none of them really does boundary checks and breaks if
>> a "new" enum value is found (even C++).
>
> In the C++ language binding, a "Foo_MAKE_FIXED_SIZE = SAL_MAX_ENUM" is
> generated for a enum type Foo. IIRC, this was introduced a few years
> ago, because of anticipated or real problems with the enum size ...

But where is it used? This is just a crutch because C++ does not have
this built-in. If the crutch is not used anywhere...

Ciao,
Mathias

--
Mathias Bauer (mba) - Project Lead OpenOffice.org Writer
OpenOffice.org Engineering at Sun: http://blogs.sun.com/GullFOSS
Please don't reply to "nospamformba@...".
I use it for the OOo lists and only rarely read other mails sent to it.

---------------------------------------------------------------------
To unsubscribe, e-mail: interface-discuss-unsubscribe@...
For additional commands, e-mail: interface-discuss-help@...

[Eike Rathke]

Hi Frank,

On Thursday, 2009-06-18 10:40:15 +0200, Frank Schönheit wrote:

> In the concrete case, I think replacing the enum with an (extensible)
> constant group is better than introducing the FilterOperator2, which
> just adds clutter to the API.
>
> We would need to explicitly check this, but in my understanding the only
> language binding where this is (compile-time) incompatible is C++. In
> Java, it should be compile-time compatible, and perhaps even
> runtime-compatible. All other language bindings should be completely
> agnostic of such a change.

If I understood correctly back years ago, changing an enum is not
possible because in Java there is the Enum object that bails out if the
value encountered during runtime doesn't match the set declared at
compile time. Someone correct me if I'm wrong on this or there are
details to add.

> > Wouldn't it make sense to specify that constant groups are extensible
> > per se, so that each code dealing with them must be able to handle
> > unknown values? Perhaps with giving hints or specifying how unknown
> > values of a particular group should be treated?
>
> Yes, would be a reasonable general guideline. Not sure we have a place
> for such guidelines, though.

Code implementing an API and dealing with constants or enums should
always have some default case to handle unknown values. If there's
a recommended treatment of unknown values in a specific constant group
or API using it, that should of course be documented in the IDL.

> > So constant groups could be changed at any time with good confidence,
> > without considering this to be "incompatible". Without this explicit
> > declaration adding constants to groups actually is incompatible, though
> > we didn't AFAIK consider it to be so when we already added numerous
> > constants to several groups.
>
> Does our watch dog bite when adding new constants to a *published*
> group?

No, it doesn't. Already did that. For obvious reasons just don't change
the value of an already existing constant. While syntactically doesn't
make it barf, it would create semantical confusion.

Long story short: I don't introduce new enums anymore but use constants
instead. This is ugly because you lose type safety of enums and maybe
other benefits, but for the penalty of not being able to add new values
it just isn't worth the hassle.

  Eike

--
 OOo/SO Calc core developer. Number formatter stricken i18n transpositionizer.
 SunSign   0x87F8D412 : 2F58 5236 DB02 F335 8304  7D6C 65C9 F9B5 87F8 D412
 OpenOffice.org Engineering at Sun: http://blogs.sun.com/GullFOSS
 Please don't send personal mail to the erl@... account, which I use for
 mailing lists only and don't read from outside Sun. Use erack@... Thanks.

[Frank Schoenheit, Sun Microsystems Germany]

Hi Eike,

>> We would need to explicitly check this, but in my understanding the only
>> language binding where this is (compile-time) incompatible is C++. In
>> Java, it should be compile-time compatible, and perhaps even
>> runtime-compatible. All other language bindings should be completely
>> agnostic of such a change.
>
> If I understood correctly back years ago, changing an enum is not
> possible because in Java there is the Enum object that bails out if the
> value encountered during runtime doesn't match the set declared at
> compile time.

Interesting. Okay, this would be a point *against* extending an enum -
at least against changing it too easily.

However, seeing the bunch of Foo2 types introduced by that in the given
case, it might be ... yes yes yes, shutting up now :)

Thanks & Ciao
Frank

--
- Frank Schönheit, Software Engineer         frank.schoenheit@... -
- Sun Microsystems                      http://www.sun.com/staroffice -
- OpenOffice.org Base                       http://dba.openoffice.org -
- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -

---------------------------------------------------------------------
To unsubscribe, e-mail: interface-discuss-unsubscribe@...
For additional commands, e-mail: interface-discuss-help@...