[Libreoffice-commits] core.git: offapi/com offapi/type_reference

[Zolnai Tamás]

Hi Eike, all,

Ok, it's starting to be a bit ridiculous from that point.
Is it really the way, if I need to change the API, to create new type
like GeneralFunction2 and rewrite the whole pivot table code to use
that new type? Really this is our policy to never change API in an
incompatible way? Never?! What kind of API is that?

You wrote that Java code can bail out if it receives an unknown enum
value. This can only be a problem if somebody uses this new
functionality I added (pivot median), right? Otherwise this enum value
is not set. So you suggest that to revert that API change and also the
related new functionality to avoid somebody use this new functionality
with a 3rd party code which can't handle that. So better to not have a
functionality, than have some 3rd party code which potentially will
have problem with that functionality. Why? Who expects that an older
3rd party code can handle a new functionality without updating the
code? If a 3rd party code manipulates pivot tables, it won't work for
pivot tables with the new median function anyway, right?

I checked your suggestion how to extend API on a compatible way, but
it seems more risky than extending this GeneralFunction enum. If I
understand well your words and if I create a new type called
GeneralFunction2 and create new interfaces also (I see about 5 such
interfaces) and also rewrite the whole pivot table code to use this
new API type and interfaces, then I see that it can lead to regression
very easily. I don't think that it's worth it. I don't see that either
if the pivot table code uses GeneralFunction2, but a 3rd party code
calles API functions with GeneralFunction how it will work. What is
needed to make GeneralFunction to be mapped to Generalfunction2.

Best Regards,
Tamás

> On Monday, November 21, 2016 15:20 GMT, Eike Rathke <erack at redhat.com> wrote:
>
>> Hi Tamás,
>>
>> On Monday, 2016-11-21 13:43:18 +0000, Tamás Zolnai wrote:
>>
>> >  offapi/com/sun/star/sheet/GeneralFunction.idl |   14 ++++++--------
>> >  offapi/type_reference/offapi.idl              |   18 +++++++++---------
>>
>> This is a no-go, already the previous commit
>> eb27a63a38ee7d15292dc40520b0605e4c2228e2 was.. if you have to modify> offapi/type_reference/offapi.idl then obviously you're introducing an
>> incompatible change, and the type_reference should *never* be modified,
>> as it exactly checks API against incompatibilites with existing API.>
>> In this case extending an enum with a new value, even if appended, may
>> cause problems with existing Java programs, if it receives an unknown> enum value it will bail out.
>>
>> Because css::sheet::GeneralFunction is used as readable property, as> return value and also as a member in css::sheet::SubTotalColumn that can
>> be returned these changes are not acceptable. Please revert:
>>
>> commit eabfd1b60f8e181e0ef2721e716210390528f4ce
>> Author: Tamás Zolnai <tamas.zolnai at collabora.com>
>> Date:   Mon Nov 21 13:57:29 2016 +0000
>>
>> commit eb27a63a38ee7d15292dc40520b0605e4c2228e2
>> Author: Tamás Zolnai <zolnaitamas2000 at gmail.com>
>> Date:   Sat Nov 19 22:27:20 2016 +0100
>>
>>
>> To introduce new values one has to create a new type, best constant as
>> constant values can be extended, add a new optional property using that
>> type, overriding the old enum, derive a new interface using the type for
>> all interfaces that use GeneralFunction and derive a new struct for
>> SubTotalColumn to also use GeneralFunction. Yes this is painful.. and> a reason to never introduce enum types again.
>>
>> For an example see commit 4c4976f717b3ddce68a872dffc2079ae49c41616