Namespaces, file names,...

[Christian Stimming]

Zitat von Derek Atkins <warlord at mit.edu>:
>> I agree that filenames should reflect the class that they implement,
>> when they do so, and I’ll add that in general a file should implement
>> only one class. Capitalization is OK as long as one keeps in mind that
>> the Mac file system is normally case-preserving but case-insensitive,
>> so e.g. Account.h and account.h will map to the same file.
>>
>> I don’t think we want to give each directory its own namespace. I’m
>> not even sure that we want any namespaces inside ‘gnucash’.
>
> I kind of like the Ruby on Rails method, where the file name is the
> lower-case snake form of the class name.  E.g., a class Account would be
> in a source file account.[ch], a class ScheduledTransaction would be in
> a file scheduled_transaction.[ch], etc.

Glib/gtk has a scheme similar to what you mentioned from ruby, just  
with one extra third variation: The typedefs are CamelCase, the file  
names are with the same spelling but all-lowercase, and the function  
names are in snake form.

And: Sorry to object, but I particularly dislike this scheme - it  
means the file names are always different from the class names. Why  
not making them completely identical? In that case, zero thoughts have  
to be spent on how to guess the correct file name for a given class.

> I agree that we don't need to have a directory for the namespace, and I
> also don't think we need to have namespaces for each "module/library".
> E.g., I don't think we need GnuCash::Engine::Account.  I suspect doing
> so would just add complexity where it might not be warranted.

I don't want to vote for extra namespaces, but I'd like to point out  
one technical reason for someone's preferences here: If the preferred  
tool of coding is something cmdline-based or emacs, chances are that  
extra directories mean extra typing work and are rather avoided. If  
the tool of coding is an IDE such as eclipse, qtcreator, or Visual  
Studio, the directories play only a minor role anymore (if visible at  
all in the project view) and chances are that they get to be used more  
often, for grouping of similar things and such. And in C++ (just as in  
java), adding extra namespaces for extra directories can be seen as  
the mapping between the file system and the compiler. In such a  
context, one wants to use gnc::engine::Account, knowing that it  
resides in the header file <gnc/engine/Account.h> on the disk, or  
gnc::backend::xml::XmlFile, knowing that it resides in  
<gnc/backend/xml/XmlFile.h>. You can always get rid of the namespace  
qualifications by using (no pun intended) "using namespace", but I  
know from my own learning curve that multiple namespaces seem rather  
smelly when coming from a C background. After years of C++ I got to  
like them, especially if they are implemented as a direct mapping from  
the directory structure on disk to the class structure in the  
namespaces. But that's just my personal take on this.

Regards,

Christian