Re: Some issues with the codebase

[Albert Strasheim]

Hello,

On Thu, 09 Jan 2003, Federico Montesino Pouzols wrote:

> On Thu, Jan 02, 2003 at 07:29:55PM +0200, Albert Strasheim wrote:
> >
> > While looking at some of the code in Common C++, I've noticed a few 
> > general issues that we might want to address.
> > 
> > Firstly, identifier names. Here's an important quote from the C++ 
> > standard via mozilla.org's C++ portability guide, available at
> > http://www.mozilla.org/hacking/portable-cpp.html,
> > 
> > "Certain sets of names and function signatures are always reserved to 
> > the implementation:
> > 
> >     * Each name that contains a double underscore (__) or begins with an 
> > underscore followed by an uppercase letter (2.11) is reserved to the 
> > implemenation for any use.
> >     * Each name that begins with an underscore is reserved to the
> > implementaiton for use as a name in the global namespace."
> > 
> > I've seen many member variables whose names start with an underscore. As 
> > far as I understand, this is Very, Very Evil(TM). If you really want an 
> > underscore in your identifier name, stick it on the end.
> > 
> 
>       I agree, many people discourage the use of leading underscores
> and there are good reasons for doing so. I believe there is no clear
> convention for this in Common C++. Personally, I would suggest to use
> trailing underscores in data members as a new recommendation for
> contributions, modifications and new code.

I don't quite agree with using only a trailing underscore. Invariably 
you're going to make a typo somewhere, and leave out an underscore, 
which could be pretty disastrous if you start calling your parameters 
in your constructors and "set" methods the same as the members, without 
the underscore.

CppUnit seems to call all their member variables "m_<membername>". I 
haven't decided if this convention is optimal, or whether it qualifies 
as some kind of quasi-Hungarian notation (Very, Very Evil(TM)), but I 
think it's better than the trailing underscore convention.

I'd be interested to hear what other people suggest in this regard.

> > Secondly, what's up with the Common C++ namespace being called "ost"? I 
> > assume this stands for Open Source Telecom? If another company were to 
> > contribute code to this project, are we going to start seeing "acme" and 
> > other namespaces too? :-)
> > 
> > I think Common C++ deserves a vendor-neutral namespace, say... mmm... 
> > "ccxx"? :-)
> 
>       Well, from the beginning most of the development has been done
> by ost, so the choice of ost as namespace seems logical and fair. We
> could provide the alternative ccxx namespace, though it could lead to
> some confusion. Moreover, since ost is a corporation that truly and
> widely supports free software, I, as a free software developer who has
> found many troubles, and finally impossible to develop free software
> for software corporations, like that the merits of ost be
> recognized. In fact, ost is rather conspicuous about its support for
> free software. I think it is really good to find free software deeply
> related to commercial corporations. Hopefully, in the future we will
> see more free software created and mostly developed by commercial
> corporations, which perhaps looks a somewhat uncommon thing as opposed
> to free software projects that are created by independent volunteers
> and thus are vendor-neutral as for names.

I totally agree with you; companies should contribute more to open 
source projects. I try to encourage this whenever I can.

However, I don't think you've really addressed my issues with company 
names in namespaces. What if a new company, say ACME Inc., takes an 
active interest in developing Common C++ and contributes much code. 
Are we then going to split stuff up into "ost" and "acme" namespaces?
I think not.

If OST wants recognition (which they richly deserve) for the work they 
have done on Common C++, stick an OST logo on the Common C++ homepage 
(unless this violates some kind of GNU homepage guideline). They will 
get much more recognition through this. You can't really miss the 
copyright notices either.

All other things aside, IMHO, the namespace of a C++ library is not the 
place to advertise the developer(s) of the code.
 
>       Of course, this is my personal point of view. If you or
> someone else in the list disagree, I would like to further discuss
> this issue.

I hope you will reconsider my arguments. I'm not trying to be different, 
I'm just trying to help establish a great library.

> > To provide backward compatability for a while, I think following 
> > declaration sprinkled through some of the headers will do the trick:
> > 
> > #ifdef CCXX_NAMESPACES
> > /**
> >  * Old Common C++ namesspace (DEPRECATED).
> >  */
> > namespace ost
> > {
> >   using namespace ccxx;
> > }
> > #endif
> > 
> > Don't know exactly how one convinces doxygen to add a description for a 
> > namespace, but anyway.
> > 
> 
>       There is a \namespace command, and I think the rules for
> namespaces are the same as for classes.

Cool.

Cheers,

Albert