Hi, I thought this was an issue with enums or attributes. I assumed adding methods shouldn't be a problem (Last time I tried building by changing the published class caused compilation to fail).
Ok, I will move that to another .idl then... Sorry for the troubles.. Thanks & Regards, Muthu Subramanian On 06/29/2011 08:09 PM, Caolán McNamara wrote: > 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
