[gmx-developers] Future developments

[Mark Abraham]

David van der Spoel wrote:
> Mark Abraham wrote:
>> David van der Spoel wrote:
>>> Erik Lindahl wrote:
>>>> Hi,
>>>>
>>>> On Feb 24, 2009, at 1:35 PM, David van der Spoel wrote:
>>>>
>>>>> Hi,
>>>>>
>>>>> yesterday I put a question on the developer list on where to put a 
>>>>> new mini-library for statistics. Right now it is used only from the 
>>>>> analysis tools but it might also be used from other parts of the 
>>>>> code. Hence I suggested placement in gmxlib, or even directly in 
>>>>> src. If no one object I will do this later today.
>>>>>
>>>>> More in general, we should decide on the future structure of the 
>>>>> source tree, do we want a src directory with dozens of 
>>>>> subdirectories, or should it be hierarchical. Do we move to one 
>>>>> library or do we keep four different ones?
>>>> Long-term I'd say we want one library, but with proper namespaces :-)
>>>
>>> What does that mean in C?
>>
>> Nothing good :-)
>>
>> You can simulate it by requiring prefixes to function and/or variable 
>> names, so kernel__mdrunner(), but you need some convention to keep 
>> clear what bit is the namespace name and what is the function name.
>>
>> You can also declare a struct full of pointers to functions which are 
>> only defined statically, so that you'd have to call kernel.mdrunner(). 
>> The kernel function arrays are essentially doing this already :-) The 
>> approach comes with the upside of being partially object-oriented.
> 
> Either of these have the problem that it is not obvious what kernel 
> means :(. Very bad name indeed, I apologize. The nonbonded kernels are 
> in src/gmxlib/nonbonded and grompp.c and mdrun.c etc. are in src/kernel.

Ack. That's a bad pair of examples from me. Lesson: don't write code at 
1am. I'd meant to evoke the idea of a "kernel" namespace from the 
existing src/kernel directory structure. Then at the last moment I 
thought of the similarity of the second approach with the way the 
nonbonded *routines* get called. Sorry for perpetuating the kludge!

Mark