[Libreoffice] cppu::OPropertySetHelper ABI backwards compatibility

[Lionel Elie Mamane]

On Mon, Aug 22, 2011 at 11:53:59PM +0200, Eike Rathke wrote:
> On Monday, 2011-08-22 15:30:04 -0400, Kohei Yoshida wrote:

>> What this tells me is that, we can't change OPropertySetHelper
>> implementation, at least not in a way that changes its virtual
>> function table (until LibreOffice 4 I suppose), which cripples us
>> since there are still opportunities to improve that code.

> There may be a way out of it: _append_ the new virtual function
> after all existing. This works only though if new code using it is
> not mixed with old implementation. Old code using the new
> implementation shouldn't see a problem as it expects the vtable to
> be shorter, unless someone derived from OPropertySetHelper then
> there may be problems again. Maybe too vague.

And won't *other* stuff be moved around? For example, because the
vtable is longer, m_pReserved is at another offset in the class,
breaking ABI again?

>> BTW, I have no idea why this base helper class is even subject to
>> frozen ABI, guarded tightly with versioned map files that don't
>> even guarantee ABI compatibility with previous versions
>> (apparently).  To me, this seems like an act of strangling
>> ourselves with no gain.

> Maybe due to some overzealous introduction of such helper
> implementations into the UDK. Sure, it eases development of
> applications, but at the costs we're facing now.

The more helper we give to extensions, the less bugs they will have
and the more they will conform to interfaces we want them to conform
to. Looks like it can be worth the cost. And thus not to put
OPropertySetHelper2 in non-stable ABI ground.

-- 
Lionel