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. 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. 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. 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. 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. Kohei -- Kohei Yoshida, LibreOffice hacker, Calc <kohei.yosh...@suse.com> _______________________________________________ LibreOffice mailing list LibreOffice@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/libreoffice
