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. _______________________________________________ LibreOffice mailing list LibreOffice@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/libreoffice
