[API] Some more cleanup ideas
Jan Holesovsky
kendy at suse.cz
Mon Dec 3 03:33:23 PST 2012
Hi all,
Michael Meeks píše v Po 03. 12. 2012 v 10:00 +0000:
> > Well, that needs some amount of explanation, too, since the nested
> > namespace is still there, and needs to be used when implementing an
> > interface.
>
> Well - IMHO it's far easier to explain 'api' on an ongoing basis than
> 'com::sun::star::' truncated to 'css' ;-)
I agree :-)
> > Personally I like api slightly better, but I simply lack
> > the time today. If someone signs up for that, then let's please also
> > change _all_ occurences of css in implementation code, _and_ the SDK
> > examples.
>
> Sounds reasonable to me.
Based on the discussion on the IRC, I've used 'lo::' in the patch,
instead of the too generic 'api::'. The patch is split into 2, so that
we do not have to patch sc/ immediately due to the ongoing work there.
http://artax.karlin.mff.cuni.cz/~kendy/tmp/0001-API-Change-css-to-lo.patch
http://artax.karlin.mff.cuni.cz/~kendy/tmp/0002-API-Change-css-to-lo-in-sc-too.patch
I have even the 'api::' version around, but it seems to me that
generally people seemed to be happier with the less general 'lo::' [and
it is shorter ;-)].
Regarding the other concerns - we definitely do not want / cannot change
the com.sun.star in the .rdbs etc. due to our goal of keeping as much
ABI compatibility as possible. But my view here is that as soon as you
start seeing that something is named lo::blah::something in the core,
but com::sun::star::blah::something in the rdb or somewhere, you are
already advanced enough not to be confused by such a thing.
Please let me know if this is acceptable :-)
All the best,
Kendy
More information about the LibreOffice
mailing list