[Libreoffice-bugs] [Bug 111811] The ImplementationName " com.sun.star.comp.math.FormulaDocument was changed to upper case "M" in " .Math." New incompatibilities!

[bugzilla-daemon at bugs.documentfoundation.org]

https://bugs.documentfoundation.org/show_bug.cgi?id=111811

--- Comment #8 from Wolfgang Jäger <jag at psilosoph.de> ---
(In reply to Stephan Bergmann from comment #7)
> 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 comment 3 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 comment 3 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 comment 0 and comment 6 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 comment 6 : 
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).

-- 
You are receiving this mail because:
You are the assignee for the bug.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.freedesktop.org/archives/libreoffice-bugs/attachments/20170816/9b7a387e/attachment-0001.html>