[Libreoffice] consistent namespaces & future breakage ...

[Michael Meeks]

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.meeks at novell.com  <><, Pseudo Engineer, itinerant idiot