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

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@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@collabora.com>
> > > Date:   Mon Nov 21 13:57:29 2016 +0000
> > >
> > > commit eb27a63a38ee7d15292dc40520b0605e4c2228e2
> > > Author: Tamás Zolnai <zolnaitamas2000@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