Re: [Libreoffice] Proposing a new Easy Hack - project consistent namespaces

2011-04-20 Thread Júlio Hoffimann
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
LibreOffice@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/libreoffice


Re: [Libreoffice] Proposing a new Easy Hack - project consistent namespaces

2011-04-19 Thread Bjoern Michaelsen
Hi Júlio,

On Tue, 19 Apr 2011 20:49:57 -0300
Júlio Hoffimann
 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


signature.asc
Description: PGP signature
___
LibreOffice mailing list
LibreOffice@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/libreoffice


Re: [Libreoffice] Proposing a new Easy Hack - project consistent namespaces

2011-04-19 Thread Cor Nouws

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
LibreOffice@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/libreoffice


Re: [Libreoffice] Proposing a new Easy Hack - project consistent namespaces

2011-04-19 Thread Christian Lohmaier
Hi *,

2011/4/20 Júlio Hoffimann :
> 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
LibreOffice@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/libreoffice


Re: [Libreoffice] Proposing a new Easy Hack - project consistent namespaces

2011-04-19 Thread Júlio Hoffimann
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
> LibreOffice@lists.freedesktop.org
> http://lists.freedesktop.org/mailman/listinfo/libreoffice
>
>
___
LibreOffice mailing list
LibreOffice@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/libreoffice


Re: [Libreoffice] Proposing a new Easy Hack - project consistent namespaces

2011-04-19 Thread Bjoern Michaelsen
Hi Caolán,

On Tue, 19 Apr 2011 09:55:59 +0100
Caolán McNamara  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


signature.asc
Description: PGP signature
___
LibreOffice mailing list
LibreOffice@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/libreoffice


Re: [Libreoffice] Proposing a new Easy Hack - project consistent namespaces

2011-04-19 Thread Júlio Hoffimann
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 

> > 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
LibreOffice@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/libreoffice


Re: [Libreoffice] Proposing a new Easy Hack - project consistent namespaces

2011-04-19 Thread Tor Lillqvist
> 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
LibreOffice@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/libreoffice


Re: [Libreoffice] Proposing a new Easy Hack - project consistent namespaces

2011-04-19 Thread Júlio Hoffimann
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
LibreOffice@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/libreoffice


Re: [Libreoffice] Proposing a new Easy Hack - project consistent namespaces

2011-04-19 Thread Joop Kiefte
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 :
>>  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
> LibreOffice@lists.freedesktop.org
> http://lists.freedesktop.org/mailman/listinfo/libreoffice
>
>
___
LibreOffice mailing list
LibreOffice@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/libreoffice


Re: [Libreoffice] Proposing a new Easy Hack - project consistent namespaces

2011-04-19 Thread Júlio Hoffimann
>
>  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
LibreOffice@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/libreoffice


Re: [Libreoffice] Proposing a new Easy Hack - project consistent namespaces

2011-04-19 Thread Lubos Lunak
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
 l.lu...@suse.cz
___
LibreOffice mailing list
LibreOffice@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/libreoffice


Re: [Libreoffice] Proposing a new Easy Hack - project consistent namespaces

2011-04-19 Thread Júlio Hoffimann
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 

> 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
> LibreOffice@lists.freedesktop.org
> http://lists.freedesktop.org/mailman/listinfo/libreoffice
>
___
LibreOffice mailing list
LibreOffice@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/libreoffice


Re: [Libreoffice] Proposing a new Easy Hack - project consistent namespaces

2011-04-19 Thread Caolán McNamara
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
LibreOffice@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/libreoffice


Re: [Libreoffice] Proposing a new Easy Hack - project consistent namespaces

2011-04-16 Thread Júlio Hoffimann
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
LibreOffice@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/libreoffice