Proposal for a standard for D library naming

[Bruno Medeiros]

Gregor Richards wrote:
> Bruno Medeiros wrote:
>> Lars Ivar Igesund wrote:
>>
>>> Bruno Medeiros wrote:
>>>
>>>> Gregor Richards wrote:
>>>>
>>>>>         o The only rule is that any module must be in the most
>>>>> specifically-named library corresponding to that module. That is, 
>>>>> if you
>>>>> have libD.a.b.so.0 and libD.a.so.0, the module a.b.c should be in
>>>>> libD.a.b.so.0, not libD.a.so.0. Doing otherwise is fairly ridiculous
>>>>> anyway.
>>>>>
>>>>>
>>>>>
>>>> Why so? Why should a given library be splited across multiple so/dll
>>>> files according to package, instead of being compiled in just one file?
>>>>
>>>>
>>>
>>> You totally missed the point, if the library _is_ split, then there 
>>> should
>>> be a standardized way to decide which part a module is in.
>>>
>>
>> I see.
>>
>> Well, But then I think it is a bad code "convention" to have 
>> subdivisions (packages) are not at the same level. That means that one 
>> should either have:
>>   a.*   // a lib with 'a' and all subpackages and modules
>> or have:
>>   // three related libs, each with it's subpackages and modules.
>>   a.b.*
>>   a.c.*
>>   a.d.*
>> This means that in the second option, package 'a' cannot have 
>> sub-modules, only sub-packages.
>>
> 
> No it doesn't - the rule is that a module is in the /most specific/ 
> library.  So, if you wanted to split out a.b, a.c and a.d, but had a 
> module a.mod, there would be a library libD.a.{so,a,lib,whatever}, but 
> it would only contain the module a.mod, no subpackages.  A library is 
> not assumed to be fully inclusive - it is assumed to be inclusive of 
> everything that isn't in a more specifically-named library.
> 
>  - Gregor Richards
> 
> PS: Yes, I thought this all through :)

It doesn't have to in *your* rule. But I was not describing your rule, I 
was describing mine. That is, I was saying that I would prefer a rule 
where a lib named "foo.{so|a|lib|whatever}" would mean that the lib 
"foo" contains all sub-packages of 'foo', not just the sub-modules.

Since that lib is almost surely dependent on that packages. No, it is 
just not dependent one those packages, it is *made by* those packages. 
And what if those packages change between versions, can you imagine the 
confusion? Consider these two versions of the same lib:

lib.foo.1.so
lib.foo.bar.1.so
lib.foo.gok.1.so

lib.foo.2.so
lib.foo.bar.2.so
lib.foo.newgok.2.so
lib.foo.zap.2.so

Now see how they look sorted in a lib dir:

lib.foo.1.so
lib.foo.2.so
lib.foo.bar.1.so
lib.foo.bar.2.so
lib.foo.gok.1.so
lib.foo.newgok.2.so
lib.foo.zap.2.so

It's quite a mess.

-- 
Bruno Medeiros - MSc in CS/E student
http://www.prowiki.org/wiki4d/wiki.cgi?BrunoMedeiros#D