[Libreoffice] cppu::OPropertySetHelper ABI backwards compatibility

[Eike Rathke]

Hi Kohei,

On Monday, 2011-08-22 15:30:04 -0400, Kohei Yoshida wrote:

> On Mon, 2011-08-22 at 20:52 +0200, Eike Rathke wrote:
> > This is why API marked as published shall not be changed after a
> > release
> > and you see all the XName2 derived from XName and so on. 
> 
> Sure.  But we are talking about the concrete implementation of the API,
> not the API itself.

Sorry, overlooked that one. Still, mixing implementation gives the
offset problem and thus we have an ABI (not API) stability problem.

> So, in that sense, cppu::OPropertySetHelper implements those published
> interfaces, which is fine.  And my recent change adds new interface to
> it.  The existing interfaces are not changed in anyway.
> 
> 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.

> I have an evil idea.  Let's just duplicate this class in full, create a
> new header and source file.  Don't even bother with sub-classing it from
> OPropertySetHelper since that would make it more complicated.

I don't see why deriving would be more complicated.

> Then have the forms implementation class sub-class from the new,
> duplicated class with the new functionality, while leaving the original
> helper class untouched.
> 
> Then, when LibreOffice 4 hits, we just remove the original, frozen
> class, then rename the new class to become the new OPropertySetHelper.

Would of course work. If there's consensus that LO4 will break existing
API, otherwise we'd have to maintain two parallel implementations. But,
I don't see a real advantage in this over sub-classing.

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

Regarding the versioned map files: they don't help against these C++
vtable traps, but are fine if one introduces new classes or
(non-virtual) methods.

  Eike

-- 
 PGP/OpenPGP/GnuPG encrypted mail preferred in all private communication.
 Key ID: 0x293C05FD - 997A 4C60 CE41 0149 0DB3  9E96 2F1A D073 293C 05FD
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 198 bytes
Desc: Digital signature
URL: <http://lists.freedesktop.org/archives/libreoffice/attachments/20110822/a703c59f/attachment.pgp>