View previous topic :: View next topic |
Author |
Message |
sean
Joined: 24 Jun 2004 Posts: 609 Location: Bay Area, CA
|
Posted: Thu Dec 15, 2005 2:14 pm Post subject: The std namespace |
|
|
Personally, I don't find 'std' to be particularly meanful as a namespace name. Assuming the namespace were to be split, can anyone suggest an alternate package layout? And what about std.c? Perhaps the C headers are the only thing that should live in std at the moment? This is something I'd like to have settled before too terribly long. My only real concern here is that it will make building Phobos apps against Ares even more difficult if std disappears, but perhaps that's a worthwhile sacrifice? |
|
Back to top |
|
|
kris
Joined: 27 Mar 2004 Posts: 1494 Location: South Pacific
|
Posted: Thu Dec 15, 2005 2:48 pm Post subject: |
|
|
What did you have in mind? Something like Mango perhaps?
ares.text
ares.convert
ares.io
ares.icu
ares.locks
ares.xml
ares.c
ares.http.x
ares.math.x
ares.sys
? |
|
Back to top |
|
|
sean
Joined: 24 Jun 2004 Posts: 609 Location: Bay Area, CA
|
Posted: Thu Dec 15, 2005 2:59 pm Post subject: |
|
|
Pretty much, yes. What I don't like about 'std' is that it's pretty much a grab bag of functionality, so when additional packages are added (like ares.icu) I think it will become unclear just where things live. Moving functionality into more specific namespaces seems more meaningful, and it will allow modules to be grouped more effectively. At the moment, Ares has a few logical groups:
* Memory Management: std.gc
* Concurrency: std.thread, std.atomic
* Compiler support: std.intrinsic
* Error Handling: std.exception
Perhaps simply this?
ares.c / ares.std.c
ares.c.posix / ares.std.c.posix
ares.sys
ares.sys.c.windows
ares.sys.c.linux
ares.alloc
ares.error
ares.concurrent (this one is a bit longer than I'd like)
ares.math
Also, std.intrinsic needs to go somewhere (if the compiler will let it). Perhaps an ares.compiler or ares.native? Or should these maybe become globally available like Object is? |
|
Back to top |
|
|
kris
Joined: 27 Mar 2004 Posts: 1494 Location: South Pacific
|
Posted: Thu Dec 15, 2005 3:17 pm Post subject: |
|
|
Yeah. The hard part is getting some logical grouping going on, that remains constant
For example, you have ares.alloc, ares.error, ares.concurrent all at the top level. Should these really go under ares.lang? Should the modules of ares.concurrent really live in ares.sys instead? Ares.math should probably be split right away into something like Don C was discussing (statistics, etc) ?
I found it took the best part of a year for the Mango namespace to settle down, and there's still a bit of movement now and again |
|
Back to top |
|
|
sean
Joined: 24 Jun 2004 Posts: 609 Location: Bay Area, CA
|
Posted: Thu Dec 15, 2005 3:58 pm Post subject: |
|
|
Ack! Hrm... I suppose the alternative would be to preserve the existing structure (with std and sys as the only default top-level packages) and add grouped functionality beneath std. So we might have:
ares.std.math
ares.std.io
etc.
Then, addon modules would be added as top-level packages, so we might have:
ares.icu
etc.
I suppose the advantage of this design is that it's less subject to administrative corrections, with some sacrifice in logical arrangement. Coming from a C++ background, this doesn't seem too bad, though I imagine it could be irksome for Java folks. |
|
Back to top |
|
|
kris
Joined: 27 Mar 2004 Posts: 1494 Location: South Pacific
|
Posted: Thu Dec 15, 2005 4:31 pm Post subject: |
|
|
Seems reasonable.
We'd often talked about a "compatability box" for phobos ~ is that still tenable? If so, you might box all the "legacy" stuff into the std corner, and build a new set of top layers as you suggest? With the expectation that folk will eventually prefer the new layers? |
|
Back to top |
|
|
sean
Joined: 24 Jun 2004 Posts: 609 Location: Bay Area, CA
|
Posted: Thu Dec 15, 2005 5:13 pm Post subject: |
|
|
That seems reasonable, though adding the compatibility layer will make Ares a pretty substantial library. Unless 'std' becomes an addon library like 'icu'? That also returns to the original question of how to divide existing functionality into more appropriate groups--and I'm not entirely certain how to do so. I suppose I'll check the Java namespace grouping and see how it's arranged. |
|
Back to top |
|
|
kris
Joined: 27 Mar 2004 Posts: 1494 Location: South Pacific
|
Posted: Thu Dec 15, 2005 5:29 pm Post subject: |
|
|
yes ~ one could treat all of std as an optional compatability box.
You may actually have to retain a little std just to keep the compiler happy (std.intrinsic, as you mentioned), but that package could get overlaid with phobos.std, as desired by the user? Only phobos.std though ... it would be rather awkward to support the std.x subfolders also, I imagine. And std.Thread would perhaps need to be patched?
BTW: is there a clean way to alias part of an import? I'm thinking that perhaps this optional phobos package might be called something else? If so, the path would need to be aliased. Alternatively, one might have a special "compatability" import that provides aliases for all phobos modules? Sound bogus perhaps, but there's really not that many modules? |
|
Back to top |
|
|
sean
Joined: 24 Jun 2004 Posts: 609 Location: Bay Area, CA
|
Posted: Thu Dec 15, 2005 5:51 pm Post subject: |
|
|
kris wrote: | yes ~ one could treat all of std as an optional compatability box.
You may actually have to retain a little std just to keep the compiler happy (std.intrinsic, as you mentioned), but that package could get overlaid with phobos.std, as desired by the user? Only phobos.std though ... it would be rather awkward to support the std.x subfolders also, I imagine. And std.Thread would perhaps need to be patched? |
phobos.std.thread would need a pretty serious overhaul. I think it would effectively act as a wrapper for the Ares thread class. And I agree that there's no point in supporting the subfolders. std.interface is likely nonstandard anyway, and Ares has better C support than Phobos, so...
[code]BTW: is there a clean way to alias part of an import? I'm thinking that perhaps this optional phobos package might be called something else? If so, the path would need to be aliased. Alternatively, one might have a special "compatability" import that provides aliases for all phobos modules? Sound bogus perhaps, but there's really not that many modules?[/quote]
I'm not sure. Managing a the files themselves would be pretty easy, so I'm not averse to that method. I thought I might just copy phobos.std into the Ares tree somewhere and handle updates manually, much as I am with the GC and runtime libraries. Assuming the compatibility layer is added however, would it be best to put it in 'std' or should it go somewhere else like 'phobos'? I can think of advantages and disadvantages to either method. |
|
Back to top |
|
|
kris
Joined: 27 Mar 2004 Posts: 1494 Location: South Pacific
|
Posted: Thu Dec 15, 2005 6:03 pm Post subject: |
|
|
I think the alias notion has merit, then. Seems more useful to me to have an ares.phobos package rather than an ares.std ~ the latter implies that it's standard, or something
If so, then a user could import ares.phobos.compatability, and all the aliases would be then in place ~ redirecting, for example, std.file into phobos.file. Or redirecting std.c.xyz over to ares.c.xyz ?
This whole ares.phobos package would stll be optional though. |
|
Back to top |
|
|
sean
Joined: 24 Jun 2004 Posts: 609 Location: Bay Area, CA
|
Posted: Thu Dec 15, 2005 6:17 pm Post subject: |
|
|
Oh I see. So the Phobos stuff would go in ares.phobos, but then what would go in ares.phobos_compat (or whatever)? Just a collection of one-line files that publicly import stuff from ares.phobos? |
|
Back to top |
|
|
kris
Joined: 27 Mar 2004 Posts: 1494 Location: South Pacific
|
Posted: Thu Dec 15, 2005 6:31 pm Post subject: |
|
|
sean wrote: | Oh I see. So the Phobos stuff would go in ares.phobos, but then what would go in ares.phobos_compat (or whatever)? Just a collection of one-line files that publicly import stuff from ares.phobos? |
Oh, I didn't really think of that as a sub-folder ~ was imagining just one module/file called "compatability" with a bunch of aliases in it. A user might perhaps have to manually import that one, though there's probably a few different ways to handle the redirection? For example, a "-version=phobos" might cause Object.d to publicly import the compatability/redirection module? |
|
Back to top |
|
|
sean
Joined: 24 Jun 2004 Posts: 609 Location: Bay Area, CA
|
Posted: Thu Dec 15, 2005 6:43 pm Post subject: |
|
|
Can you actually alias module names? I had no idea. |
|
Back to top |
|
|
kris
Joined: 27 Mar 2004 Posts: 1494 Location: South Pacific
|
Posted: Thu Dec 15, 2005 7:15 pm Post subject: |
|
|
sean wrote: | Can you actually alias module names? I had no idea. |
I had just assumed so, but that's completely wrong ~ bang goes that idea, then |
|
Back to top |
|
|
kris
Joined: 27 Mar 2004 Posts: 1494 Location: South Pacific
|
|
Back to top |
|
|
|