Hi guys,
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
uno:: perhaps).
* un-'publish' a lot of pointlessly published interfaces -
eg. the UNO accessibility API is never going to be used
externally.
* 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
code periphary
* 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
* etc.
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.
ATB,
Michael.
--
michael.me...@novell.com <><, Pseudo Engineer, itinerant idiot
_______________________________________________
LibreOffice mailing list
LibreOffice@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/libreoffice
