FAQFAQ   SearchSearch   MemberlistMemberlist   UsergroupsUsergroups   RegisterRegister 
 ProfileProfile   Log in to check your private messagesLog in to check your private messages   Log inLog in 

The std namespace
Goto page 1, 2  Next
 
Post new topic   Reply to topic     Forum Index -> Ares
View previous topic :: View next topic  
Author Message
sean



Joined: 24 Jun 2004
Posts: 609
Location: Bay Area, CA

PostPosted: Thu Dec 15, 2005 2:14 pm    Post subject: The std namespace Reply with quote

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
View user's profile Send private message
kris



Joined: 27 Mar 2004
Posts: 1494
Location: South Pacific

PostPosted: Thu Dec 15, 2005 2:48 pm    Post subject: Reply with quote

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
View user's profile Send private message
sean



Joined: 24 Jun 2004
Posts: 609
Location: Bay Area, CA

PostPosted: Thu Dec 15, 2005 2:59 pm    Post subject: Reply with quote

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
View user's profile Send private message
kris



Joined: 27 Mar 2004
Posts: 1494
Location: South Pacific

PostPosted: Thu Dec 15, 2005 3:17 pm    Post subject: Reply with quote

Yeah. The hard part is getting some logical grouping going on, that remains constant Smile

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 Twisted Evil
Back to top
View user's profile Send private message
sean



Joined: 24 Jun 2004
Posts: 609
Location: Bay Area, CA

PostPosted: Thu Dec 15, 2005 3:58 pm    Post subject: Reply with quote

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
View user's profile Send private message
kris



Joined: 27 Mar 2004
Posts: 1494
Location: South Pacific

PostPosted: Thu Dec 15, 2005 4:31 pm    Post subject: Reply with quote

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
View user's profile Send private message
sean



Joined: 24 Jun 2004
Posts: 609
Location: Bay Area, CA

PostPosted: Thu Dec 15, 2005 5:13 pm    Post subject: Reply with quote

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
View user's profile Send private message
kris



Joined: 27 Mar 2004
Posts: 1494
Location: South Pacific

PostPosted: Thu Dec 15, 2005 5:29 pm    Post subject: Reply with quote

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
View user's profile Send private message
sean



Joined: 24 Jun 2004
Posts: 609
Location: Bay Area, CA

PostPosted: Thu Dec 15, 2005 5:51 pm    Post subject: Reply with quote

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
View user's profile Send private message
kris



Joined: 27 Mar 2004
Posts: 1494
Location: South Pacific

PostPosted: Thu Dec 15, 2005 6:03 pm    Post subject: Reply with quote

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 Smile

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
View user's profile Send private message
sean



Joined: 24 Jun 2004
Posts: 609
Location: Bay Area, CA

PostPosted: Thu Dec 15, 2005 6:17 pm    Post subject: Reply with quote

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
View user's profile Send private message
kris



Joined: 27 Mar 2004
Posts: 1494
Location: South Pacific

PostPosted: Thu Dec 15, 2005 6:31 pm    Post subject: Reply with quote

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
View user's profile Send private message
sean



Joined: 24 Jun 2004
Posts: 609
Location: Bay Area, CA

PostPosted: Thu Dec 15, 2005 6:43 pm    Post subject: Reply with quote

Can you actually alias module names? I had no idea.
Back to top
View user's profile Send private message
kris



Joined: 27 Mar 2004
Posts: 1494
Location: South Pacific

PostPosted: Thu Dec 15, 2005 7:15 pm    Post subject: Reply with quote

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 Crying or Very sad
Back to top
View user's profile Send private message
kris



Joined: 27 Mar 2004
Posts: 1494
Location: South Pacific

PostPosted: Thu Dec 15, 2005 7:36 pm    Post subject: Reply with quote

Another daft idea: on linux one can create aliases upon the file system ~ I bet that would work with imports Twisted Evil

Can one do the same thing on Win32?

Edit: it appears you can ~ sort of:

Hard linking for individual files: http://schinagl.priv.at/nt/hardlinkshellext/hardlinkshellext.html

Soft linking for folders: http://www.rekenwonder.com/linkmagic.htm

And here too: http://www.codeproject.com/w2k/junctionpoints.asp

From the command-line, fsutil supports making hard links only.
Back to top
View user's profile Send private message
Display posts from previous:   
Post new topic   Reply to topic     Forum Index -> Ares All times are GMT - 6 Hours
Goto page 1, 2  Next
Page 1 of 2

 
Jump to:  
You cannot post new topics in this forum
You cannot reply to topics in this forum
You cannot edit your posts in this forum
You cannot delete your posts in this forum
You cannot vote in polls in this forum


Powered by phpBB © 2001, 2005 phpBB Group