[Libreoffice] changing published idls is a tricky business

[Muthu Subramanian K]

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.
>