<html> <head> <base href="https://bugs.documentfoundation.org/"> </head> <body> <div> <a class="bz_bug_link bz_status_UNCONFIRMED " title="UNCONFIRMED - The ImplementationName "com.sun.star.comp.math.FormulaDocument was changed to upper case "M" in ".Math." New incompatibilities!" href="https://bugs.documentfoundation.org/show_bug.cgi?id=111811#c8">Comment # 8</a> on <a class="bz_bug_link bz_status_UNCONFIRMED " title="UNCONFIRMED - The ImplementationName "com.sun.star.comp.math.FormulaDocument was changed to upper case "M" in ".Math." New incompatibilities!" href="https://bugs.documentfoundation.org/show_bug.cgi?id=111811">bug 111811</a> from <a class="email" href="mailto:jag@psilosoph.de" title="Wolfgang Jäger <jag@psilosoph.de>"> Wolfgang Jäger</a> <pre>(In reply to Stephan Bergmann from <a href="show_bug.cgi?id=111811#c7">comment #7</a>) > This is a bit complicated: > ... > ... > > 3rd-party code should not rely on the implementation names of UNO objects. > Some such code certainly does, for various reasons. In <a href="show_bug.cgi?id=111811#c3">comment 3</a> Wolfgang > Jäger states that two questioners in forums had issues with this, but leaves > it unclear how severe those issues were (i.e., whether it actually broke > existing code). I was very clear about this in <a href="show_bug.cgi?id=111811#c3">comment 3</a> and elsewhere. (Too many words, probably.) I stated it was myself who experienced the issue when trying to help the questioners. I stated I knew a workaround. > ... In <a href="show_bug.cgi?id=111811#c0">comment 0</a> and <a href="show_bug.cgi?id=111811#c6">comment 6</a> he remains vague ("most likely", > "no bug report about it was filed seemingly") on whether the current state > has known bad consequences. I thought I was clear about NOT knowing FORMERLY occurring consequences. The issue I mentioned above I solved by testing for the service "com.sun.star.formula.FormulaProperties" using 'supportsService' instead of for an ImplementationName by explicit string comparison. (Testing for services I prefer anyway generally.) But: If the names of services and interfaces also are "subject to change" under something like the above quoted statement by Stephan Bergmann, how should someone write long-term-reliable code ("3rd-party") for special requirements or for a distributable extension? How should a decider be sure an investment in document automation based on LibreOffice for a large organisation would pay instead of just creating problems? Where old naming differences in source files occur, a main concern should be that the one(?) naming is persistent which is returned if a respective object is asked by code running for a document. > Thus, unless evidence of known bad consequences is brought forward, I would > like to close this issue as WONTFIX. (And will do so if there's no new > input coming.) I would still insist that my comments were rather clear. As I am not an insider the terminology may have flaws. Once again from my <a href="show_bug.cgi?id=111811#c6">comment 6</a> : I would like to hear that developers will be aware of the fact that any tiny change in the field can afflict code. If a piece of code like mine ceases working, well... (no big problem), but if a valuable and widespread extension fails... It should also be clear that the failing I observed concerned compatibility with AOO and backward/forward compatibility between LibO versions. No objections against WONTFIX. Objections against future changes in names (if avoidable at all).</pre> </div> <hr> You are receiving this mail because: <ul> <li>You are the assignee for the bug.</li> </ul> </body> </html>