There have been a lot of good ideas and points made about this in the
discussions here. The upshot is there isn't a single right answer,
but there are a few clearly wrong ones <g>. So it's up to me to just pick
one of the right answers.

So here goes:

std
 Contains the 'standard' modules that will be available on all
 implementations of D. Emphasis in this package will be on reliability,
 stability, and portability. std as a name has the advantage of being used
 in C++ to specify the standard library, and so is familiar and highly
 unlikely to conflict with common variable names.

std.c
 Contains D interfaces to standard C library functions, like
 std.c.stdio, std.c.stdlib, std.c.math.

std.os
 Access to platform specific functionality.

std.os.windows
 Specific to win32 and win64 operating systems. (win64
 is coming, so calling it 'win32' would be a mistake.)
 The excellent point was raised about operating system
 specific code not being in the std tree as it evolves
 constantly. I understand that point, but operating systems
 evolve by adding API's, not subtracting them. So any
 windows package should continue to work as long as there's
 a windows operating system.

std.os.linux
 Specific to linux operating systems.

std.typeinfo
 Where the various TypeInfo implementations go.

internal
 Internal magic implementation-specific runtime support code.

etc
 There are lots of 'other' modules for D, and right now there is no
 organized way to deal with them. There needs to be a place for them.
 The etc heirarchy will mirror the standard one, i.e. there will
 be etc.c, etc.os.windows, ... These will not be official parts of D
 nor will they be standardized. However, candidates for standardization
 will be drawn from etc. etc is the place for
 not-quite-there-yet-but-still-useful modules.

These names have the advantage of being reasonably greppable.

Major packages, such as a D gui, will merit their own toplevel name. Vendor specific modules will use a toplevel name being the trademarked vendor name. For example, vendor BrandX would put their vendor specific packages under the toplevel name brandx.

Much as I'd prefer to use D or d as the toplevel name, it just isn't going to work because of conflicts, non-greppability, etc.

Walter wrote:
> There have been a lot of good ideas and points made about this in the
> discussions here. The upshot is there isn't a single right answer,
> but there are a few clearly wrong ones <g>. 
Thanks for not singling out anyone for humilitation...

> So it's up to me to just pick
> one of the right answers.
> 
> So here goes:
> 
> std
>  Contains the 'standard' modules that will be available on all
>  implementations of D. Emphasis in this package will be on reliability,
>  stability, and portability. std as a name has the advantage of being used
>  in C++ to specify the standard library, and so is familiar and highly
>  unlikely to conflict with common variable names.

So in the future, we'll be talking about std.string, std.regexp, std.thread, std.uri, std.utf and others?  (I'm trying to make sure that I understand.)

> 
> std.c
>  Contains D interfaces to standard C library functions, like
>  std.c.stdio, std.c.stdlib, std.c.math.
> 
> std.os
>  Access to platform specific functionality.
> 
> std.os.windows
>  Specific to win32 and win64 operating systems. (win64
>  is coming, so calling it 'win32' would be a mistake.)
>  The excellent point was raised about operating system
>  specific code not being in the std tree as it evolves
>  constantly. I understand that point, but operating systems
>  evolve by adding API's, not subtracting them. So any
>  windows package should continue to work as long as there's
>  a windows operating system.
> 
> std.os.linux
>  Specific to linux operating systems.
> 
> std.typeinfo
>  Where the various TypeInfo implementations go.
> 
> internal
>  Internal magic implementation-specific runtime support code.
(Pixie dust, I presume.)

> 
> etc
>  There are lots of 'other' modules for D, and right now there is no
>  organized way to deal with them. There needs to be a place for them.
>  The etc heirarchy will mirror the standard one, i.e. there will
>  be etc.c, etc.os.windows, ... These will not be official parts of D
>  nor will they be standardized. However, candidates for standardization
>  will be drawn from etc. etc is the place for
>  not-quite-there-yet-but-still-useful modules.
> 
> These names have the advantage of being reasonably greppable.
> 
> Major packages, such as a D gui, will merit their own toplevel name. Vendor
> specific modules will use a toplevel name being the trademarked vendor name.
> For example, vendor BrandX would put their vendor specific packages under
> the toplevel name brandx.
> 

Sounds like a good plan.  (I'm glad that I don't have to put my packages in "other.com.tripod.jcc_7".)

> Much as I'd prefer to use D or d as the toplevel name, it just isn't going
> to work because of conflicts, non-greppability, etc.
Thanks for being persuadable.

Justin
http://jcc_7.tripod.com/d/

Is this the official final word?

Is this the official final structure?

I'm pretty happy with it as is, although I'd like to see a std.lang where language bits reside.

Oh, and a std.c.recls. :)

"Walter" <walter@digitalmars.com> wrote in message news:bnn9a0$1o09$1@digitaldaemon.com...
> There have been a lot of good ideas and points made about this in the
> discussions here. The upshot is there isn't a single right answer,
> but there are a few clearly wrong ones <g>. So it's up to me to just pick
> one of the right answers.
>
> So here goes:
>
> std
>  Contains the 'standard' modules that will be available on all
>  implementations of D. Emphasis in this package will be on reliability,
>  stability, and portability. std as a name has the advantage of being used
>  in C++ to specify the standard library, and so is familiar and highly
>  unlikely to conflict with common variable names.
>
> std.c
>  Contains D interfaces to standard C library functions, like
>  std.c.stdio, std.c.stdlib, std.c.math.
>
> std.os
>  Access to platform specific functionality.
>
> std.os.windows
>  Specific to win32 and win64 operating systems. (win64
>  is coming, so calling it 'win32' would be a mistake.)
>  The excellent point was raised about operating system
>  specific code not being in the std tree as it evolves
>  constantly. I understand that point, but operating systems
>  evolve by adding API's, not subtracting them. So any
>  windows package should continue to work as long as there's
>  a windows operating system.
>
> std.os.linux
>  Specific to linux operating systems.
>
> std.typeinfo
>  Where the various TypeInfo implementations go.
>
> internal
>  Internal magic implementation-specific runtime support code.
>
> etc
>  There are lots of 'other' modules for D, and right now there is no
>  organized way to deal with them. There needs to be a place for them.
>  The etc heirarchy will mirror the standard one, i.e. there will
>  be etc.c, etc.os.windows, ... These will not be official parts of D
>  nor will they be standardized. However, candidates for standardization
>  will be drawn from etc. etc is the place for
>  not-quite-there-yet-but-still-useful modules.
>
> These names have the advantage of being reasonably greppable.
>
> Major packages, such as a D gui, will merit their own toplevel name.
Vendor
> specific modules will use a toplevel name being the trademarked vendor
name.
> For example, vendor BrandX would put their vendor specific packages under the toplevel name brandx.
>
> Much as I'd prefer to use D or d as the toplevel name, it just isn't going to work because of conflicts, non-greppability, etc.
>
>

> > std
> >  Contains the 'standard' modules that will be available on all
> >  implementations of D. Emphasis in this package will be on reliability,
> >  stability, and portability. std as a name has the advantage of being
used
> >  in C++ to specify the standard library, and so is familiar and highly
> >  unlikely to conflict with common variable names.
>
> So in the future, we'll be talking about std.string, std.regexp, std.thread, std.uri, std.utf and others?  (I'm trying to make sure that I understand.)

I hope not. Shouldn't string, regexp and the like go "under" something else, and shouldn't "thread" go under std.lang?

In article <bnng70$20up$1@digitaldaemon.com>, Matthew Wilson says...
>

Allow me to suggest

stdd

"std" on google gets 6.470.00
"stdd" gets 4.700

Ant

"J C Calvarese" <jcc7@cox.net> wrote in message news:bnnb81$1qem$1@digitaldaemon.com...
> So in the future, we'll be talking about std.string, std.regexp, std.thread, std.uri, std.utf and others?  (I'm trying to make sure that I understand.)

Yes. I also tend to prefer flatter, more populated heirarchies, rather than deep, thinly populated heirarchies like:

    std.this.that.foo.bar.common.implementation.abc.thread.

"Matthew Wilson" <matthew-hat@-stlsoft-dot.-org> wrote in message news:bnng71$20up$2@digitaldaemon.com...
> I hope not. Shouldn't string, regexp and the like go "under" something
else,
> and shouldn't "thread" go under std.lang?

Why?

"Ant" <Ant_member@pathlink.com> wrote in message news:bnnglq$21fi$1@digitaldaemon.com...
> In article <bnng70$20up$1@digitaldaemon.com>, Matthew Wilson says...
> >
>
> Allow me to suggest
>
> stdd
>
> "std" on google gets 6.470.00
> "stdd" gets 4.700

D gets 315,000,000 <g>.

Interestingly, std.thread gets 369, std.string gets 102,000, std.regexp gets 8.

"Matthew Wilson" <matthew-hat@-stlsoft-dot.-org> wrote in message news:bnng70$20up$1@digitaldaemon.com...
> Is this the official final word?
> Is this the official final structure?

Unless someone points out a disastrous problem with it <g>.

> I'm pretty happy with it as is, although I'd like to see a std.lang where language bits reside.

I'm just going for a workable system, having long since given up on perfection. Let's just cut & print and move on to more interesting things!

>
> Oh, and a std.c.recls. :)

Isn't it a language feature, rather than a library feature?

Maybe thread wasn't the best example. The class info stuff?

"Walter" <walter@digitalmars.com> wrote in message news:bnnjkd$2683$1@digitaldaemon.com...
>
> "Matthew Wilson" <matthew-hat@-stlsoft-dot.-org> wrote in message news:bnng71$20up$2@digitaldaemon.com...
> > I hope not. Shouldn't string, regexp and the like go "under" something
> else,
> > and shouldn't "thread" go under std.lang?
>
> Why?
>
>