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

[Zolnai Tamás]

Hi Kendy,

I wrote down my opinion. Sorry if I went to far with that word
"ridiculous". Ignore that paragraph and you have what I should say on
an ESC call. I would not bother with this API stability/instability
anymore in general. I'm interested in only this specific case.
Discuss it on ESC if needed and send me your decision. I can't do
anything more with that.

Thanks,
Tamás

2016-11-21 22:16 GMT+01:00 Jan Holesovsky <kendy at collabora.com>:
> Hi Tamas,
>
> I fear this is not the best way to communicate this...  Can you please
> join the ESC call on Thursday? - I think it will be a better place to
> discuss the API stability & instability.
>
> Thank you,
> Kendy
>
> Zolnai Tamás píše v Po 21. 11. 2016 v 20:14 +0000:
>> 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
>> _______________________________________________
>> LibreOffice mailing list
>> LibreOffice at lists.freedesktop.org
>> https://lists.freedesktop.org/mailman/listinfo/libreoffice
>
>