Hi, > * 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. Thanks, Tamás _______________________________________________ LibreOffice mailing list LibreOffice@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/libreoffice