View previous topic :: View next topic |
Author |
Message |
sean
Joined: 24 Jun 2004 Posts: 609 Location: Bay Area, CA
|
Posted: Wed Oct 06, 2004 2:30 pm Post subject: Separating DMD and Phobos |
|
|
I finally decided to take a closer look at the overlap between DMD and Phobos and so far I've found a few files that will have to be looked at: asserterror.d, intrinsic.d, gc.d, outofmemory.d, and moduleinit.d. DMD definately relies on all of these, and I think it may be correct to have them in "std" where they are now. So that raises some questions:
Does this stuff belong in "std?"
Assuming it does, should object.d be put there as well?
Should we attempt to extract Phobos into its own namespace within Ares, and if so, where do these files belong? |
|
Back to top |
|
|
kris
Joined: 27 Mar 2004 Posts: 1494 Location: South Pacific
|
Posted: Wed Oct 06, 2004 3:13 pm Post subject: Re: Separating DMD and Phobos |
|
|
sean wrote: | I finally decided to take a closer look at the overlap between DMD and Phobos and so far I've found a few files that will have to be looked at: asserterror.d, intrinsic.d, gc.d, outofmemory.d, and moduleinit.d. DMD definately relies on all of these, and I think it may be correct to have them in "std" where they are now. So that raises some questions:
Does this stuff belong in "std?"
Assuming it does, should object.d be put there as well?
Should we attempt to extract Phobos into its own namespace within Ares, and if so, where do these files belong? |
I'd be tempted to suggest that those files actually belong with the other compiler dependencies within the 'internal' subdirectory. They are presumably necessary components, that the compiler cannot build an operational executable without. That is, one does not import moduleinit.d to get a working program (much like object.d). One might think of these as "compiler helpers", even though Walter didn't place them in the "internal" location (although one can explicitly import from either location, if one wishes).
Regardless, I tend to feel that such functionality belongs to the implicit runtime support, whereas the "libraries" might be viewed as explicit runtime support (because one has to explicitly import them). As such, they might live in a completely seperate namespace (or even a seperate library, for that matter). That is, perhaps these modules (along with typeinfo.* and all the various internal\ modules) should live in a compiler.* or runtime.* namespace. Or perhaps they should all be in a secondary library outside of Phobos as it currently stands today (one which belongs to Walter, or some other D implementer). After all, don't all of those belong to the compiler proper?
One question might be: which of these modules (including all the internal\.* and typeinfo modules) are needed for compilation purposes, and which ones are present in Phobos purely for linker resolution only?
Another might be: which of these modules belong to the compiler-writer, or might be changed due to an implementation-specific idiom? Presumeably, such modules should be isolated away from our efforts? |
|
Back to top |
|
|
sean
Joined: 24 Jun 2004 Posts: 609 Location: Bay Area, CA
|
Posted: Wed Oct 06, 2004 3:22 pm Post subject: |
|
|
I agree, but the exceptions got me wondering. So move this stuff (plus typeinfo) into /internal and make it accessible at the global level, much like object.d is now. I'll give this a try and see how it goes. |
|
Back to top |
|
|
kris
Joined: 27 Mar 2004 Posts: 1494 Location: South Pacific
|
Posted: Wed Oct 06, 2004 6:21 pm Post subject: |
|
|
sean wrote: | I agree, but the exceptions got me wondering. So move this stuff (plus typeinfo) into /internal and make it accessible at the global level, much like object.d is now. I'll give this a try and see how it goes. |
Walter has noted that only the location of Object.d is explicit within the compiler, and everything else is just linked via Phobos. This means that
1) those compiler-related modules can all live within /internal, if appropriate, after making the appropriate namespace changes.
2) all of /internal could be placed within a seperate lib, such that they are made the explicit property of the compiler developer only. That is, one might place all the /internal stuff into an internal.lib for now, and everything else into an ares.lib (or whatever it's called). Worth a try?
3) Object.d can probably stay where it is (as part of /internal), since it has no namespace prefix anyway. Perhaps it should become a 'skeleton' class, in the manner that's suggested for hidden implementation? That way, the source for Object.d can be part of the standard package, but the implementation is actually hidden within Object.obj (via internal.lib, or wherever it ultimately resides).
Note that the printf() reference should probably be removed from Object.d, and the opCmp() referencing std.string may have to be 'scrutinized' carefully. It may be fine to just duplicate the string comparison for the time being, until we decide whether the opCmp() should be abandoned within Object.d (per the enthusiastic NG discussions).
Just thoughts ... |
|
Back to top |
|
|
|
|
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
|