[Libreoffice] consistent namespaces & future breakage ...

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