[Libreoffice] consistent namespaces & future breakage ...
michael.meeks at novell.com
Wed Apr 20 07:02:06 PDT 2011
On Tue, 2011-04-19 at 23:17 +0200, Bjoern Michaelsen wrote:
> IMHO doing a "gradual migration" is not a good idea here. Such
> things should be done in one deep cut, because:
So - I think the tread came up with the right answer - which is
'later'; on this.
Nevertheless, the com::sun::star:: namespace, is not only an
anachronism, but a real source of bloat too - it makes our .rdb files
larger, it makes our symbol tables bigger and slower to resolve, it adds
bulk ~everywhere for nearly no benefit.
Having said that - I think we probably want to have a flag-day at some
stage perhaps a 4.0, and it is worth collecting things we want to do
then, so we remember to do them all - I suggest having a tracker bug for
that would be helpful. If we reconcile ourselves to breaking the plugin
ABI (and API) incompatibly, and the necessity of re-compiling plugins
for a next major version [ which seems to me to be sensible ], I guess
there are a lot of things we'd like to have then:
* drop the com::sun::star namespace (and the
org::openoffice:: one too for something short & simple
* un-'publish' a lot of pointlessly published interfaces -
eg. the UNO accessibility API is never going to be used
* replace 'sal_Bool' with 'bool' globally in UNO interfaces
* replace rtl::OUString with a UTF-8 string for better space
efficiency, and Unicode coverage.
* remove rtl::OString - and do charset conversion at the
* drop the monstrous 'store' code, and the old types.rdb file
* perhaps re-work some of the horrible UNO APIs used by scripts
to something more useful and familiar
* drop the pointless UNO-isation of the calc formula APIs
* kill the bogus Stream read method, misc. UNO API usefulness
audit, cleanup and removal
Of course, research on automated tools and scripts to get this stuff
done right quickly, would be great.
Having said this - I think this sort of disruptive change belongs in a
major version update, and I can't see it happening for the next year :-)
[ but we should prolly plan a date for it so it does end up happening ].
There is never a good time back-compatibility breakage - but now is a
particularly bad time for it I think :-)
And of course, we should extend the above list to cover all our pet
hates that we can't currently fix IMHO.
michael.meeks at novell.com <><, Pseudo Engineer, itinerant idiot
More information about the LibreOffice