[kplato] Re: koffice/kplato

[Bo Thorsen]

Hi,

(I removed the kde-cvs address since they are probably not too 
interested.)

On Monday 01 November 2004 11:35, Raphael Langerhorst wrote:
> On Monday 01 November 2004 08:11, Bo Thorsen wrote:
> > On Saturday 30 October 2004 19:02, Raphael Langerhorst wrote:
> > > CVS commit by raphael:
> > >
> > > Updated the copyright year to 2004 in about data,
> > > added information in the tODO file how to grep FIXME and TODO
> > > items from source files, added entry about namespaces (still to
> > > discuss on mailinglist) in TODO file.
> > > [snip]
> > > +-           Use KPlato namespace for all KPlato classes
> >
> > Why would you want to use a namespace for application code? It
> > doesn't help.
> >
> > Bo.
>
> Ok, this is something we still need to discuss: namespaces. I'll start
> with a reference to koffice/kspread/DESIGN.html:
>
> When creating a new class, use namespace KSpread. Legacy code will be
> someday converted into namespaces but in the mean time do not use
> KSpread prefix anymore. Example: use KSpread::Foo instead of
> KSpreadFoo. Also source file name should not contain kspread prefix
> anymore, i.e. foo.h and foo.cc (but not kspread_foo.h and
> kspread_foo.cc) for the above example.
>
> The project I'm mainly working on (G System) also uses namespaces for
> every part of the Project. As gcc now supports namespaces I think
> it's acceptable to think of a good/clean source code structure. Using
> namespaces results in a better structured code IMHO. It's a bit like
> designing tables for databases (ER diagrams). You don't want a column
> that let's you enter a name like "Raphael Langerhorst", but normally
> you want two columns, one for your first name, the other for your
> last name, this allows for better data handling. It's quite the same
> with sourcecode. If we're naming classes KPTProject for example then
> we could also call it KOKPTProject (KOffice KPlato Project). Of
> course we do not use the KOffice prefix as well (but it should show
> the issue). It would be better to use sth. like KPlato::Project, then
> it's clear that it is the project class of kplato and it is possible
> to distuingish between class type (Project) and where it belongs to
> (the KPlato software or namespace). That's like distuingishing
> between first and last name of a person ("Raphael" and
> "Langerhorst").
>
> I guess at the moment the benefits are not so clearly visible, but in
> the long term using namespaces results in better code reusability and
> management, especially in large projects.
>
> What do you think?

I know several projects where they put all classes in a specific 
namespace.

The problem with it is that there is no reason to do so, unless you plan 
on converting the code to be a library later.

Encapsulating something in a namespace is wise when you don't want to 
pollude the global namespace. But if noone will ever link to your code, 
then you can only be polluding the namespace of your own application. 
This is the reason it doesn't make much sense to put application classes 
in a specific namespace. I've never liked the kpt prefix to all files and 
classes either, for the exact same reason. If you feel it's best to 
decide between the kpt prefix and using a namespace, I feel a namespace 
is the right tool. Prefixes are way too 80'ish.

As a case in point, KMail used to have a km prefix for all files and KM 
for classes. Currently, there is one guy who believes that the backend of 
KMail will be a library or a service at some point, so he puts everything 
in a KMail namespace. But everyone else believes it's just an application 
(or that it's a trivial task to later add the namespace everywhere 
necessary) so almost all new code in KMail is without a namespace or a 
prefix. However, when we do refactor classes into the libraries of 
kdepim, then we of course use the right namespace for that library.

It's entirely different for libraries. Here it should be considered very 
bad practice not to keep the global namespace clean, so application 
programmers do not experience namespace clashes.

BTW, it's been quite a long time since I worked on KPlato, so I don't feel 
I have any real saying in this matter. I do have a big urge on getting 
back into it, but I just started my own consulting business and I just 
don't have any time at all for non-paid work :-( However, I still have 
high hopes for the project, so consider all of yourselves cheered on by 
me :-)

Bo.

(Keep me CCed since I'm not on the kplato list.)
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 189 bytes
Desc: not available
Url : http://mail.kde.org/pipermail/kplato/attachments/20041101/2461500c/attachment.pgp