Proposal for a standard for D library naming

[Gregor Richards]

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.

> 
> 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.

> 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

This is not the standard way of naming UNIX library versions, but OK, 
continuing ...

> 
> 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

Makes sense to me.

> 
> It's quite a mess.
> 

I see no mess.

  - Gregor Richards