Proposal for a standard for D library naming
Gregor Richards
Richards at codu.org
Thu Sep 28 13:19:48 PDT 2006
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
More information about the Digitalmars-d
mailing list