Summary: | Incompatible API changes between versions: provide better support, information at runtime, .. for all API users | ||
---|---|---|---|
Product: | LibreOffice | Reporter: | tim |
Component: | LibreOffice | Assignee: | Not Assigned <libreoffice-bugs> |
Status: | NEW --- | ||
Severity: | enhancement | CC: | cno, lionel, ooo, sberg.fun, tim |
Priority: | medium | ||
Version: | unspecified | ||
Hardware: | All | ||
OS: | All | ||
Whiteboard: | |||
Crash report or crash signature: | Regression By: | ||
Bug Depends on: | 70949 | ||
Bug Blocks: | 117710 |
Description
tim
2013-10-28 08:19:41 UTC
Hi tim, What information channels/means would you suggest? Are you aware of what is currently done to inform users/developers? thanks, Cor I'm aware of the release notes. People need to read these before installing new versions. I might suggest that where there's a backwards incompatibility this could be flagged more strongly. However, these notes don't help in writing code compatible with multiple versions of LO (or OO). For that, one needs to be able to detect the change at run-time. That's what I am asking for. thanks Tim. Is the summary as I made it now fine for you? Cor Almost OK, but it isn't just for extension developers, it is for anyone writing macros of any sort in their own organisation's applications. As a matter of example, here is how to detect the alluded to change. 't would be nice if someone posted it on some documentation / FAQ / code snippets website. Dim OOoReflection As Object Set OOoReflection = CreateUnoService("com.sun.star.reflection.CoreReflection") Dim gD as Object Set gD = OOoReflection.forName("com.sun.star.awt.XDateField").getMethod("getDate").ReturnType if gD.TypeClass = com.sun.star.uno.TypeClass.LONG then gbDateIsStruct = false elseif gD.TypeClass = com.sun.star.uno.TypeClass.STRUCT And gD.Name = "com.sun.star.util.Date" then gbDateIsStruct = true else MsgBox "Unknown situation" end if (In reply to comment #0) > There should therefore be functions to obtain information about the version, > such as GetOfficeVersion and GetOfficeName and GetOfficeVendor. People can > then write code that works on the different versions. I agree that having utility functions to easily get version information is good; I disagree that using them to "adapt" code is a good idea. If possible, feature tests (rather than version tests) are more robust. > For changes to behaviour based on types of data items there should also be > simple functions to find out what the data type of an item in a control is. That's exactly what the above code does. The control implements an interface, and that code looks what data type that interface gives. As an example of "other change", if the control used to implement interface XFoo1 but now does not, then that's the "right thing" to test: does it implement interface "XFoo1"? > All such incompatible changes need to be flagged in advance Yeah, that one was rather "last minute". But OTOH, even if we had done it months before release, I'm still not clear on how to announce it in a way that users will notice. (In reply to comment #5) > > All such incompatible changes need to be flagged in advance > > Yeah, that one was rather "last minute". But OTOH, even if we had done it > months > before release, I'm still not clear on how to announce it in a way that users > will notice. Bug 70667 tries to address that. |