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 <[email protected]> > > 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 <[email protected]> > >> Date: Mon Nov 21 13:57:29 2016 +0000 > >> > >> commit eb27a63a38ee7d15292dc40520b0605e4c2228e2 > >> Author: Tamás Zolnai <[email protected]> > >> 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 > [email protected] > https://lists.freedesktop.org/mailman/listinfo/libreoffice _______________________________________________ LibreOffice mailing list [email protected] https://lists.freedesktop.org/mailman/listinfo/libreoffice
