[Libreoffice-qa] minutes of ESC call ...
zolnaitamas2000 at gmail.com
Thu Nov 24 18:34:07 UTC 2016
> * Pivot-Tables / UNO / API evolution (Eike)
> + current state looks good (Eike)
> + new feature will work.
> + what needs clarification in future: when & how to break stable API
> + if not absolutely necessary - don't do it.
> + adding a new constant is more work & more ugly.
> + new interface / Function2 bits is uglier for the API users (Stephan)
> + will there be further extensions of that list of functions ?
> + yes ? (Michael)
> + perhaps not (Eike)
> + if this is the only change this century - say go with incompatible change (Stephan)
> + if will be further additions likely; perhaps pay the price now.
> + dug at why addition to enums is incompatible (Kendy)
> + fail to see why we should consider it incompatible.
> + from semantic POV - fair cop.
> + but everything we do is controlled by us
> + code generated, JARs we generate from newer version.
> + can generate some odd code here - that would cause issues.
> + with normal use-cases; get a value of enum, do something, put it back.
> + reasonably transparent.
> + perhaps some scenario fails; if someone tries to cast random integers into
> enums or no real technical reason not to extend an enum.
> + problem with out-of-process Java code & older JAR file (Stephan)
> + if you bundle JAR file with ext'n or app - have an issue (Kendy)
> + mostly a moot discussion wrt. danger of extending it (Stephan)
> + using constant-groups instead.
> + Function - to a Constant Group ? (Thorsten)
> + already done etc.
> + Concern wrt. tone on each side (Thorsten, Michael)
> + revert first and then discuss seems reasonable close to branch (Norbert)
> + real problem is the UNO API used internally (Markus)
> + long-term solution - to get rid of UNO API for internal code.
> + happy to see this separated (Eike)
> + could get the XPropertySet / Any to accept different types incoming (Michael)
> + doesn't help so much for reading.
> + What is the view wrt. changing byte-code we generate ? (Kendy)
> + from 5.3 or 5.4 - so we can change the enums safely.
> + codemaker magic - that needs some modification ?
> + no-one looked into the .Net binding (Stephan)
> + don't see a way to change the Java code.
> + need an object representing that value
> + don't see the value.
> + if we hit a place where an incompat way is preferred (Stephan)
> + we just do that.
> + enum situation in the past was a hard-wall (Kendy)
> + larger API changes - asking consider changes here.
> + in the future -> say - add a FUTURE_ITEMS (Michael)
> + then people get warned; we never emit this etc.
> + not sure we get anything here, but if want to do it - why not ? (Stephan)
> => anyone welcome to look into improving this.
> + FWIW - Tamas' spare-time fun improvement (Michael)
> + concern that we consider 3rd party apps carefully as we move ahead (Thorsten)
Thanks for discussing this, even tough this discussion did not lead to change.
I have only one question for the future, if it ever comes into my mind
to implement something which is related to this DAPI.
Can I have some code pointers from the last 5 years which shows when
it is "absolutely necessary" to break compatibility? To see when it's
acceptable to do such thing.
More information about the Libreoffice-qa