Sean Kelly wrote:
> Don wrote:
>>
>> 'std', 'stdc' and 'sys' sound OK to me. Although is there any reason why stdc couldn't be part of 'sys'?
>> IMHO: 'common' sounds far too generic. 'core' is borderline.
> 
> My current thought is to have:
> 
> core/
>     stdc/
>     sys/posix
>     sys/windows
> 
> (yes, I'm planning to move posix support out of stdc)
> 
> Alternatives to core are: lang, d, base...  But I like core the best so far.
> 
> 
> Sean

vote++;

On Wed, 22 Oct 2008 20:42:05 +0200, Sean Kelly <sean@invisibleduck.org> wrote:

> Don wrote:
>>  'std', 'stdc' and 'sys' sound OK to me. Although is there any reason why stdc couldn't be part of 'sys'?
>> IMHO: 'common' sounds far too generic. 'core' is borderline.
>
> My current thought is to have:
>
> core/
>      stdc/
>      sys/posix
>      sys/windows
>
> (yes, I'm planning to move posix support out of stdc)
>
> Alternatives to core are: lang, d, base...  But I like core the best so far.
>
>
> Sean

core is good. d or base also, but I think core is the best.

-- 
Simen

Sean Kelly:
> Alternatives to core are: lang, d, base...  But I like core the best so far.

"d" is the name of the package my libs, so I hope you will use something different :-) (But this isn't really much important).

A possible organization (if technically possible) that looks more symmetric to me is to keep the std as core and push the rest of phobos into a phobos package:

import std.gc; // the common core
import phobos.md5; // from Phobos
import tango.foo; // from tango

In Python standard modules aren't in a top-level package, so you just do:

import collections
from gc import enable, disable

Following that Python style it may become:

import gc; // the common core
import phobos.md5; // from Phobos
import tango.foo; // from tango

Bye,
bearophile

On Thu, Oct 23, 2008 at 6:22 AM, bearophile <bearophileHUGS@lycos.com> wrote:
> Sean Kelly:
>> Alternatives to core are: lang, d, base...  But I like core the best so far.
>
> "d" is the name of the package my libs, so I hope you will use something different :-) (But this isn't really much important).

I would have thought that having a 'd' as the name of a top-level package would make it impossible to use 'd' as a local identifier.  Is that not so?

Anyway, if you have to rename it then you'll be getting what you deserve from having the meglomania to use the name of the language as your package name.

--bb

On Thu, Oct 23, 2008 at 6:22 AM, bearophile <bearophileHUGS@lycos.com> wrote:
> In Python standard modules aren't in a top-level package, so you just do:
>
> import collections
> from gc import enable, disable

But I think that's starting to bite Python in the behind as the number of std library packages increases.  Funny to have so many top level things in a language whose motto is "Namespaces are one honking great idea.  Let's do more of those."

Other responsible development organizations that release packages tend to collect them under a single top level package like "zope.*"  or "enthought.*".

There's also so many standard packages these days that when I see an unfamiliar import I'm never sure if it's a standard one or not.

--bb

Bill Baxter:
> I would have thought that having a 'd' as the name of a top-level package would make it impossible to use 'd' as a local identifier.  Is that not so?

I have had no problems so far. And my identifiers are usually a little longer, and I generally use qualified imports.

(In my opinion a well designed module system has to not import the name of the module/package when you import qualified names from it.)


> Anyway, if you have to rename it then you'll be getting what you deserve from having the meglomania to use the name of the language as your package name.

No meglomania, I think. I did chose "d" because it's short and I was unable to invent a better name... But I've I have said it's not a problem, changing the package name requires me just few minutes.

Bye,
bearophile

Bill Baxter:
> But I think that's starting to bite Python in the behind as the number of std library packages increases.

I tend to agree. That's why I have never complained for D having a "std" package name for its standard lib :-)

Bye,
bearophile

Bill Baxter wrote:
> On Thu, Oct 23, 2008 at 6:22 AM, bearophile <bearophileHUGS@lycos.com> wrote:
>> Sean Kelly:
>>> Alternatives to core are: lang, d, base...  But I like core the best so far.
>>
>> "d" is the name of the package my libs, so I hope you will use something different :-) (But this isn't really much important).
> 
> I would have thought that having a 'd' as the name of a top-level
> package would make it impossible to use 'd' as a local identifier.  Is
> that not so?

Seems it'll work as long as you don't refer to something in the 'd' package using its fully qualified name.  Then the package name will conflict with any locals named 'd'.

But the package name will always conflict with globals, at least it does when I try it with DMD 1.033.  Not that globals with single-letter names is something I'd recommend using.

torhu:
> But the package name will always conflict with globals, at least it does when I try it with DMD 1.033.  Not that globals with single-letter names is something I'd recommend using.

I see. Then I'll invent and use a different package name. Thank you.

Bye,
bearophile

Sean Kelly Wrote:

> Don wrote:
> > 
> > 'std', 'stdc' and 'sys' sound OK to me. Although is there any reason why
> > stdc couldn't be part of 'sys'?
> > IMHO: 'common' sounds far too generic. 'core' is borderline.
> 
> My current thought is to have:
> 
> core/
>      stdc/
>      sys/posix
>      sys/windows
> 
> (yes, I'm planning to move posix support out of stdc)
> 
> Alternatives to core are: lang, d, base...  But I like core the best so far.

What happens to the other parts of Phobos? Like others, I hope it will be ranamed from std to phobos.