[prev in list] [next in list] [prev in thread] [next in thread] 

List:       koffice-devel
Subject:    Re: Namespaces and class name prefix (???) (was: Re: koffice/kplato)
From:       Thomas Zander <zander () kde ! org>
Date:       2005-11-22 16:20:33
Message-ID: 200511221720.33985.zander () kde ! org
[Download RAW message or body]

[Attachment #2 (multipart/signed)]


On Tuesday 22 November 2005 16:17, Raphael Langerhorst wrote:
> Reasons FOR option 3 (namespace only)
> * The formal structuring of source code with namespaces can be utilized
> by automated tools (doxygen for instance, source code analyzers). 
> * Namespaces make clear which classes belong to a logical group (also
> automatically analyzable - thinking of tools, KDevelop, ...)

From your list, these make a difference, the others don't actually help me 
create better software.
Currently I don't see this as a good enough reason to learn about 
namespaces.
We hardly have any docs, I'd gladly reconsider if we did.
Most KOffice apps don't have many libraries, and the ones that do (kexi 
and krita) already have namespaces.


> Reasons AGAINST option 3 (namespaces only)
[edited slightly to include the con-reasons from option 2]
> * If a namespace is not closed in a 
> header file it is difficult to detect from compiler errors.
> * having only namespaces could cause an unintended name conflict
> that might not even be seen in the first moment.
> * Plus: it will be a bit of work (2-3 hours for KPlato) to get rid of
> the class name prefixes.

I worked with namespaces in KMail before and there it makes sense since 
kde-pim really exists of lot of quite separate libraries.
I quickly hated namespaces due to the compiler problems that were hard to 
understand and to the weird syntax that I really failed to grasp.  Its 
personal, yeah, but so are most of your reasons.

-- 
Thomas Zander

[Attachment #5 (application/pgp-signature)]

_______________________________________________
koffice-devel mailing list
koffice-devel@kde.org
https://mail.kde.org/mailman/listinfo/koffice-devel


[prev in list] [next in list] [prev in thread] [next in thread]