Proposing a new Easy Hack - project consistent namespaces

classic Classic list List threaded Threaded
25 messages Options
Next » 12
Júlio Hoffimann Júlio Hoffimann
Reply | Threaded
Open this post in threaded view
|

Proposing a new Easy Hack - project consistent namespaces

Hi devs,

How hard is to rename all the C++ namespaces to most comprehensive and consistent names with the project?

It would help us, external contributors, to understand the code and make substantial changes. I'm trying to get familiar, but there is a complex mix of namespaces from StarOffice/OpenOffice and other previous versions. This really don't helps.

I know, sounds crazy to rename everything, but you could pass this task for us, Easy Hackers.

And what i have in mind?

You could map the old namespaces to the names you want putting in a single header file:

$ cat changingNames.hpp

// this map should list all namespace trees:
namespace oldNameLevel_0 {
    namespace oldNameLevel_1 {

    }
}

// and you developers choose the better names:
namespace newNameLevel_0 {
    using namespace oldNameLevel_0;
    namespace newNameLevel_1 {
        using namespace oldNameLevel_1;
    }
}

// -----------------------------------------------

// another example
namespace com { namespace sun { namespace star { namespace uno {} } } }

// defining the new names for LibreOffice!
namespace libre {
    using namespace com::sun;
    namespace writer {
        using namespace star;
        namespace writerSomething {
            using namespace uno;
        }
    }
}

This file would be added in all LibreOffice source code by regexp, then even we change the names to the new ones gradually, the build would not break. In a far future, when someone remove the last trace, we done.

I think this Easy Hack is an important step for LibreOffice growth.

Regards,
Júlio.

_______________________________________________
LibreOffice mailing list
[hidden email]
http://lists.freedesktop.org/mailman/listinfo/libreoffice
Júlio Hoffimann Júlio Hoffimann
Reply | Threaded
Open this post in threaded view
|

Re: Proposing a new Easy Hack - project consistent namespaces

Hi,

Before i forget... If you think this is not a so bad idea, just let me know. Would be a pleasure to prepare the files for you. :-)

I need just a map with the new names and a file name (#include "changingName.hpp").

Best regards,
Júlio.

_______________________________________________
LibreOffice mailing list
[hidden email]
http://lists.freedesktop.org/mailman/listinfo/libreoffice
Caolán McNamara Caolán McNamara
Reply | Threaded
Open this post in threaded view
|

Re: Proposing a new Easy Hack - project consistent namespaces

In reply to this post by Júlio Hoffimann
On Fri, 2011-04-15 at 18:27 -0300, Júlio Hoffimann wrote:
> Hi devs,
>
>
> How hard is to rename all the C++ namespaces to most comprehensive and
> consistent names with the project?

Well, one fairly common pattern is sprinkled around of...

namespace css = com::sun::star;
namespace cssu = com::sun::star::uno;

Sticking e.g. an additional namespace alias of

namespace libreoffice = com::sun::star;, or something of that nature, in
some header probably isn't the worst idea in the world. Though it does
generate a lot of churn to go around changing anything, and the other
language bindings, e.g. java and so on, wouldn't be affected, which i
guess has the potential for some extra confusion.

C.


_______________________________________________
LibreOffice mailing list
[hidden email]
http://lists.freedesktop.org/mailman/listinfo/libreoffice
Júlio Hoffimann Júlio Hoffimann
Reply | Threaded
Open this post in threaded view
|

Re: Proposing a new Easy Hack - project consistent namespaces

Hi Caolán,

I was thinking in the LibreOffice identity too. Renaming the namespaces created by sun and other previous versions would help us to understand the code, but also would make we feel in a new software, a real community software. This is not so hard to do because C++ is powerful as we know, and if we try to imagine the suite in the future, is not great to maintain old names in the source, we need an identity! :-)

Again, if you approve the idea, just pass this task for us, would be a pleasure.

Thanks for reply,
Júlio.

2011/4/19 Caolán McNamara <[hidden email]>
On Fri, 2011-04-15 at 18:27 -0300, Júlio Hoffimann wrote:
> Hi devs,
>
>
> How hard is to rename all the C++ namespaces to most comprehensive and
> consistent names with the project?

Well, one fairly common pattern is sprinkled around of...

namespace css = com::sun::star;
namespace cssu = com::sun::star::uno;

Sticking e.g. an additional namespace alias of

namespace libreoffice = com::sun::star;, or something of that nature, in
some header probably isn't the worst idea in the world. Though it does
generate a lot of churn to go around changing anything, and the other
language bindings, e.g. java and so on, wouldn't be affected, which i
guess has the potential for some extra confusion.

C.


_______________________________________________
LibreOffice mailing list
[hidden email]
http://lists.freedesktop.org/mailman/listinfo/libreoffice


_______________________________________________
LibreOffice mailing list
[hidden email]
http://lists.freedesktop.org/mailman/listinfo/libreoffice
Lubos Lunak Lubos Lunak
Reply | Threaded
Open this post in threaded view
|

Re: Proposing a new Easy Hack - project consistent namespaces

On Tuesday 19 of April 2011, Júlio Hoffimann wrote:
> Hi Caolán,
>
> I was thinking in the LibreOffice identity too. Renaming the namespaces
> created by sun and other previous versions would help us to understand the
> code, but also would make we feel in a new software, a real community
> software. This is not so hard to do because C++ is powerful as we know, and
> if we try to imagine the suite in the future, is not great to maintain old
> names in the source, we need an identity! :-)

 It would probably help if you were more specific with your proposal. Renaming
things in the code just because it's now called LibreOffice is probably not
worth it (there's still enough code that has naming from the times it was
called StarOffice). Being more specific would also (hopefully) help others to
understand what improvement you expect from it - believe it or not, what you
as a newcomer may find batshit insane may look perfectly normal to long time
developers since they've simply already gotten used to it.

 If this is about those com::sun::start::whatever namespaces specifically,
then I think it's part of the UNO interfaces and as such it needs to be kept
for backwards compatibility for extensions.

--
 Lubos Lunak
 [hidden email]
_______________________________________________
LibreOffice mailing list
[hidden email]
http://lists.freedesktop.org/mailman/listinfo/libreoffice
Júlio Hoffimann Júlio Hoffimann
Reply | Threaded
Open this post in threaded view
|

Re: Proposing a new Easy Hack - project consistent namespaces

 If this is about those com::sun::start::whatever namespaces specifically,
then I think it's part of the UNO interfaces and as such it needs to be kept
for backwards compatibility for extensions.

I think this is a wrong vision, this is why the code is like it is. Maintain backwards compatibility *in this case* makes the code a mix of previous and confusing versions, we need new compatibilities. Btw, LibreOffice was born ~one year ago, "backwards" doesn't make so much sense.

Anyway, i don't have the expertise you have, my vision is superfluous. Just trying to help the project.

Regards,
Júlio.

_______________________________________________
LibreOffice mailing list
[hidden email]
http://lists.freedesktop.org/mailman/listinfo/libreoffice
Joop Kiefte Joop Kiefte
Reply | Threaded
Open this post in threaded view
|

Re: Proposing a new Easy Hack - project consistent namespaces

As this is an API issue, maybe it's an idea to create a new, cleaner,
namespace scheme first and deprecate the old way but not disable it
yet... Maybe you could think of finally removing the old namespaces
completely in LibreOffice 4 or something like that (a new mayor
version is a good moment to break API's)... This way extensions have
time to transition.

2011/4/19 Júlio Hoffimann <[hidden email]>:

>>  If this is about those com::sun::start::whatever namespaces specifically,
>> then I think it's part of the UNO interfaces and as such it needs to be
>> kept
>> for backwards compatibility for extensions.
>
> I think this is a wrong vision, this is why the code is like it is. Maintain
> backwards compatibility *in this case* makes the code a mix of previous and
> confusing versions, we need new compatibilities. Btw, LibreOffice was born
> ~one year ago, "backwards" doesn't make so much sense.
> Anyway, i don't have the expertise you have, my vision is superfluous. Just
> trying to help the project.
> Regards,
> Júlio.
> _______________________________________________
> LibreOffice mailing list
> [hidden email]
> http://lists.freedesktop.org/mailman/listinfo/libreoffice
>
>
_______________________________________________
LibreOffice mailing list
[hidden email]
http://lists.freedesktop.org/mailman/listinfo/libreoffice
Júlio Hoffimann Júlio Hoffimann
Reply | Threaded
Open this post in threaded view
|

Re: Proposing a new Easy Hack - project consistent namespaces

Hi Joop,

The first message in this conversation does exactly what you said. The change would be made gradually, the build would not break, namespaces are just aliases. When the last old name is removed, the header is not useful and should be removed by regexp again.

Regards,
Júlio.


_______________________________________________
LibreOffice mailing list
[hidden email]
http://lists.freedesktop.org/mailman/listinfo/libreoffice
Tor Lillqvist Tor Lillqvist
Reply | Threaded
Open this post in threaded view
|

Re: Proposing a new Easy Hack - project consistent namespaces

> The change would be made gradually, the build would not break, namespaces are
> just aliases.

So one would code as if stuff was in various libreoffice::foo namespaces, but in all compiler and linker error messages, in debugger backtraces in bug reports etc, one would still see the actual com::sun::star:: stuff? Sounds painful.

--tml


_______________________________________________
LibreOffice mailing list
[hidden email]
http://lists.freedesktop.org/mailman/listinfo/libreoffice
Júlio Hoffimann Júlio Hoffimann
Reply | Threaded
Open this post in threaded view
|

Re: Proposing a new Easy Hack - project consistent namespaces

Hi Tor,

This is a real problem, but i think it's necessary if we need to grow faster. Every migration or any big change is painful, i'm here now trying to remove Blitz++ dependency in a particular project to use the Boost libraries. Painful today, amazing tomorrow. :-)

Regards,
Júlio.

2011/4/19 Tor Lillqvist <[hidden email]>
> The change would be made gradually, the build would not break, namespaces are
> just aliases.

So one would code as if stuff was in various libreoffice::foo namespaces, but in all compiler and linker error messages, in debugger backtraces in bug reports etc, one would still see the actual com::sun::star:: stuff? Sounds painful.

--tml




_______________________________________________
LibreOffice mailing list
[hidden email]
http://lists.freedesktop.org/mailman/listinfo/libreoffice
Bjoern Michaelsen Bjoern Michaelsen
Reply | Threaded
Open this post in threaded view
|

Re: Proposing a new Easy Hack - project consistent namespaces

In reply to this post by Caolán McNamara
Hi Caolán,

On Tue, 19 Apr 2011 09:55:59 +0100
Caolán McNamara <[hidden email]> wrote:

> namespace libreoffice = com::sun::star;, or something of that nature,
> in some header probably isn't the worst idea in the world. Though it
> does generate a lot of churn to go around changing anything, and the
> other language bindings, e.g. java and so on, wouldn't be affected,
> which i guess has the potential for some extra confusion.

IMHO doing a "gradual migration" is not a good idea here. Such
things should be done in one deep cut, because:
- having two names for the same thing will just add to newcomer
  confusion, esp. if he ends up in a piece of code that mixes both
  happily. This will one only have benefits once it is completed and
  will even hurt in the meantime.
- historical evidence (tools string vs. sal string) shows how well
  "gradual transitions" work when not tightly enforced.
- we will not tightly enforce this one as it is not providing essential
  benefits compared to other work.
- while it is true that this can be done by EasyHackers, I really dont
  thing there is any lack of EasyHacks. There are other tasks like:
  http://wiki.documentfoundation.org/Development/Easy_Hacks#Get_rid_of_SV_DECL_VARARR.2C_SV_DECL_VARARR_PLAIN.2C_SV_DECL_VARARR_SORT_....
  (or migration to the new build system) that also only really benefit
  the project when fully completed. It is better to have one such
  EasyHacks finished (and being rewarded by the benefit) than having
  five such EasyHacks finished 20% (or even 50%) and having no benefit
  for the project whatsoever.

Just my 2 euro cents,

Bjoern

--
https://launchpad.net/~bjoern-michaelsen

_______________________________________________
LibreOffice mailing list
[hidden email]
http://lists.freedesktop.org/mailman/listinfo/libreoffice

signature.asc (501 bytes) Download Attachment
Júlio Hoffimann Júlio Hoffimann
Reply | Threaded
Open this post in threaded view
|

Re: Proposing a new Easy Hack - project consistent namespaces

The gradual migration is the only way i see to change thousand of names. Even with regular expressions, the task is not easy to do.

About the half percentage of Easy Hacks, no matters. We are doing it (in parallel), that is important. Tor was the first to say something really problematic about the migration: the bug reports, the names in the build, in the logs, etc. Again, painful today, amazing tomorrow.

I know, we are close a release, there is no chance to initiate such a migration now. I'm talking about a long-term change where you - main developers - would not realize, but we - external contributors - would learn the code naturally.

Maybe do the task module by module to mask the "giant migration"... i don't know what you want. The truth: we have fear to make big changes and this is not a good paradigm, it turns LibreOffice just another fork and it's more than that.

Regards,
Júlio.
 
IMHO doing a "gradual migration" is not a good idea here. Such
things should be done in one deep cut, because:
- having two names for the same thing will just add to newcomer
 confusion, esp. if he ends up in a piece of code that mixes both
 happily. This will one only have benefits once it is completed and
 will even hurt in the meantime.
- historical evidence (tools string vs. sal string) shows how well
 "gradual transitions" work when not tightly enforced.
- we will not tightly enforce this one as it is not providing essential
 benefits compared to other work.
- while it is true that this can be done by EasyHackers, I really dont
 thing there is any lack of EasyHacks. There are other tasks like:
 http://wiki.documentfoundation.org/Development/Easy_Hacks#Get_rid_of_SV_DECL_VARARR.2C_SV_DECL_VARARR_PLAIN.2C_SV_DECL_VARARR_SORT_....
 (or migration to the new build system) that also only really benefit
 the project when fully completed. It is better to have one such
 EasyHacks finished (and being rewarded by the benefit) than having
 five such EasyHacks finished 20% (or even 50%) and having no benefit
 for the project whatsoever.

Just my 2 euro cents,

Bjoern

--
https://launchpad.net/~bjoern-michaelsen

_______________________________________________
LibreOffice mailing list
[hidden email]
http://lists.freedesktop.org/mailman/listinfo/libreoffice



_______________________________________________
LibreOffice mailing list
[hidden email]
http://lists.freedesktop.org/mailman/listinfo/libreoffice
Christian Lohmaier-2 Christian Lohmaier-2
Reply | Threaded
Open this post in threaded view
|

Re: Proposing a new Easy Hack - project consistent namespaces

Hi *,

2011/4/20 Júlio Hoffimann <[hidden email]>:
> The gradual migration is the only way i see to change thousand of names.
> Even with regular expressions, the task is not easy to do.

Well, easy or hard to do doesn't matter, when the benefit is not so
clear to other people. I for example do not see anything that would be
"amazing tomorrow".

I just don't see the point in this. It is just work without amy
benefit to me. No benefit for the user (only trouble if at all, if the
user is using extensions that would have to be adapted), no benefit
for extension developers (they don't care how it's namespace is, they
need to find the functionality in the API), no benefit for core
developers (again, why would the name matter).

You only see the code, that's fine, but when you really want to change
this, this means you have to change the complete API documentation,
you have to tell publishers that they have to revise their books, etc.
It's just not worth the time in my opinion.

Regarding your point wrt. backwards compatibily is no problem since
LibreOffice is so young: That just doesn't fit, as it of course has
the 10 years+ of history of StarOffice and then OpenOffice.org - If
you want OOo users to migrate to LO, you cannot just say "We don't
care about what was before LO was born"...

ciao
Christian
_______________________________________________
LibreOffice mailing list
[hidden email]
http://lists.freedesktop.org/mailman/listinfo/libreoffice
Cor Nouws Cor Nouws
Reply | Threaded
Open this post in threaded view
|

Re: Proposing a new Easy Hack - project consistent namespaces

In reply to this post by Júlio Hoffimann
Júlio Hoffimann wrote (19-04-11 18:12)
> Btw,
> LibreOffice was born ~one year ago, "backwards" doesn't make so much sense.

The aim was and still is to be the continuation of.
So let's be careful with out assets, the users and companies that build
on us.

Cor


--
  - http://nl.libreoffice.org
  - giving openoffice.org its foundation :: The Document Foundation -

_______________________________________________
LibreOffice mailing list
[hidden email]
http://lists.freedesktop.org/mailman/listinfo/libreoffice
Bjoern Michaelsen Bjoern Michaelsen
Reply | Threaded
Open this post in threaded view
|

Re: Proposing a new Easy Hack - project consistent namespaces

In reply to this post by Júlio Hoffimann
Hi Júlio,

On Tue, 19 Apr 2011 20:49:57 -0300
Júlio Hoffimann
<[hidden email]> wrote:

> The gradual migration is the only way i see to change thousand of
> names. Even with regular expressions, the task is not easy to do.

There are feature branches. Absolutely no need to do this on master.

> Again, painful today, amazing tomorrow.

With "today" being the next five years. Five years that are absolutely
critical for the project.
With "amazing" being absolutely not the word I would use to describe
the result (see Christians reply too).
If this would be about renaming classes with misleading names to
something that that really describes its job or something like using
the same consistent internal variable naming scheme _that_ is helping in
the long run, ok.
Unlike that, changing one proper name "com::sun::star::" to another
"libreoffice::" is only providing minor benefits, but also has major
drawbacks.

> The truth: we have fear to make big changes and this is not a good
> paradigm, it turns LibreOffice just another fork and it's more than
> that.

Please dont tell me that I am afraid of changes. If you would know how
much I fought inside OOo for change, you would realize how ridiculous
that is.

Best,

Bjoern


--
https://launchpad.net/~bjoern-michaelsen

_______________________________________________
LibreOffice mailing list
[hidden email]
http://lists.freedesktop.org/mailman/listinfo/libreoffice

signature.asc (501 bytes) Download Attachment
Júlio Hoffimann Júlio Hoffimann
Reply | Threaded
Open this post in threaded view
|

Re: Proposing a new Easy Hack - project consistent namespaces

Thank you all for the replies, was a great discussion. :-) I won't persist in this idea, even discording in the actual situation.

Let's go back for coding...

$ cd libo/wizards/com/sun/star/wizards :-(

Regards,
Júlio.

_______________________________________________
LibreOffice mailing list
[hidden email]
http://lists.freedesktop.org/mailman/listinfo/libreoffice
Michael Meeks Michael Meeks
Reply | Threaded
Open this post in threaded view
|

consistent namespaces & future breakage ...

In reply to this post by Bjoern Michaelsen
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.

--
 [hidden email]  <><, Pseudo Engineer, itinerant idiot

_______________________________________________
LibreOffice mailing list
[hidden email]
http://lists.freedesktop.org/mailman/listinfo/libreoffice
Bjoern Michaelsen Bjoern Michaelsen
Reply | Threaded
Open this post in threaded view
|

Re: consistent namespaces & future breakage ...

Hi Michael, Hi all,

On Wed, 20 Apr 2011 15:02:06 +0100
Michael Meeks <[hidden email]>
wrote:

> 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:
>
> [... long list of snafus follows ...]

Agreed. Essentially you are proposing a new API version and to get rid
of all the known historic ugliness. I think we should start more
freeform on a wikipage before solidifying in the bug tracker at least
in the beginning, when the discussion is still very fluid. Otherwise we
would end up with endless bug splits and merges as the topics can be
highly interdependent.

> 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.

I think that is the most important point. Esp. since sometimes we might
agree that the status quo is bad, but we might not (yet) agree on how a
better solution should look like. So we should create a wikipage now
discussing all possible changes and cooking it for at least one year.
That will ensure we have a plan once we get to this and:
a) that it has been discussed well enough by the bright minds on our
   project.
b) that people using the API see what is coming and can brace for
   impact.
c) Any flamewar about the implementation will have cooled down to
   slightly below one unit of "emacs vs. vi"
d) there will be no big OMGeverythingDifferent!!11! surprises.

Best,

Bjoern



--
https://launchpad.net/~bjoern-michaelsen


_______________________________________________
LibreOffice mailing list
[hidden email]
http://lists.freedesktop.org/mailman/listinfo/libreoffice
Júlio Hoffimann Júlio Hoffimann
Reply | Threaded
Open this post in threaded view
|

Re: consistent namespaces & future breakage ...

Hi Michael,

Thanks for expose your opinion, it's so much professional than mine. :-)

Best regards,
Júlio.

_______________________________________________
LibreOffice mailing list
[hidden email]
http://lists.freedesktop.org/mailman/listinfo/libreoffice
Lubos Lunak Lubos Lunak
Reply | Threaded
Open this post in threaded view
|

Re: consistent namespaces & future breakage ...

In reply to this post by Michael Meeks
On Wednesday 20 of April 2011, Michael Meeks wrote:
> And of course, we should extend the above list to cover all our pet
> hates that we can't currently fix IMHO.

 I don't want to comment on the specific items as that could make this thread
grow into a monster, but could it be said more specifically what we cannot
fix currently? As I understand it we cannot break backwards compatibility
only for things related to extensions (UNO, what else?), but even there I'm
not sure what that all means code-wise.

--
 Lubos Lunak
 [hidden email]
_______________________________________________
LibreOffice mailing list
[hidden email]
http://lists.freedesktop.org/mailman/listinfo/libreoffice
Next » 12