[Libreoffice] changing published idls is a tricky business

Caolán McNamara caolanm at redhat.com
Wed Jun 29 07:39:07 PDT 2011


The .idl apis are sort of "frozen" things. If you insert methods into
them then something like an existing binary c++ code, in e.g. an
extension, that was compiled against an older version which calls the
third virtual method on an pre-change object will continue to call the
third virtual method if a new virtual method is inserted into the .idl
before the desired one. So, re ure:6f04c9e9, something that isn't
rebuilt that used to call setFormula probably now calls setFormulaResult
instead.

Not sure what happens in practice with the other language bindings.

If new methods are appended to the end I guess that might be less nasty
in the c++ case anyway, though it still means that if there are old
extensions that implement the api, as opposed to use it, there's no way
to know if has the potentially missing method implemented when calling
it so calls that direction will jump into hyperspace. And it won't
rebuild without implementation of the new methods, which is a lesser
problem.

The usual, if horrible, thing that happens is e.g. stuff like the
XFilePicker2 to extend the XFilePicker interface, or XFooExtended to
extend an original XFoo interface with extra methods.

We could always do a "grand-incompatible" event or something and fold
all those Foo2 back to Foo and declare that everything is out of date
and needs rebuilding, but I don't think we're doing that right now.

C.



More information about the LibreOffice mailing list