Proposal for a standard for D library naming

[Bruno Medeiros]

Gregor Richards wrote:
> Bruno Medeiros wrote:
>> 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.
> 
> That was my original thought.
> 
> But that doesn't work.
> 

Wouldn't work? Why not?

>>
>> Since that lib is almost surely dependent on that packages.
> 
> In the general case, module a.b.c is dependent on module a.c, NOT the 
> reverse.  Dependency within a tree usually goes up or across the tree, 
> not down.  Across is simply interlibrary dependency, up is where our 
> point of contention is.
> 

I'm uncertain of that. Ultimately it depends on how one organizes his 
code structure and modules, but I think an organization where modules 
are usually dependent on submodules/subpackages(and not parent ones) is 
more logical.
(In any case it doesn't affect my point about the lib file)

>>
>> 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
> 
> Makes sense to me.
> 
>>
>> It's quite a mess.
>>
> 
> I see no mess.
> 
>  - Gregor Richards

Well then, we've hit a subjective point(opinion), so not much to argue 
then. (I like the files as clean and tidy as possible)


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