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 <ke...@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 <er...@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.zol...@collabora.com> >> >> Date: Mon Nov 21 13:57:29 2016 +0000 >> >> >> >> commit eb27a63a38ee7d15292dc40520b0605e4c2228e2 >> >> Author: Tamás Zolnai <zolnaitamas2...@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@lists.freedesktop.org >> https://lists.freedesktop.org/mailman/listinfo/libreoffice > > _______________________________________________ LibreOffice mailing list LibreOffice@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/libreoffice
