[kplato] Re: koffice/kplato

[Bo Thorsen]

On Monday 01 November 2004 12:20, Bo Thorsen wrote:
> 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.

Replying to myself.

As David just pointed out, KPlato is a part. Meaning it actually is a 
library and is loaded together with other components. So the namespace 
introduction is indeed a good idea.

/me shuts up and goes away again :-)

Bo.
-------------- 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/7a5e42cc/attachment.pgp