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
Attachment:
signature.asc
Description: Digital signature