Since there's been some discussion on phobos's structure, I figured I'd add
in my $0.02 in a few suggestions:
1. move non-essential modules in to the etc tree, including but not limited
to things like std.recls and std.zlib (there is already an etc.c.zlib it
seems).
2. move all os-specific code out of std, and create a 'sys' tree
specifically for this kind of thing; thus, sys.windows.windows would replace
std.c.windows.windows, making only those elements of the C standard that we
need in std.c.
3. Perhaps we should consider moving away fron the one-module-per-OS style
of organization; we could continue to have these blanket modules, but they
would really just be importing submodules that would contain organized
definitions, types, and anything else OS-specific.
What do you all think?
--
Ameer
---
Visit my blog at
http://ameerarmaly.blogspot.com
---
Life is either tragedy or comedy.
Usually it's your choice. You can whine or you can laugh.
--Animorphs

Since there's been some discussion on phobos's structure, I figured I'd add
in my $0.02 in a few suggestions:
1. move non-essential modules in to the etc tree, including but not limited
to things like std.recls and std.zlib (there is already an etc.c.zlib it
seems).
2. move all os-specific code out of std, and create a 'sys' tree
specifically for this kind of thing; thus, sys.windows.windows would replace
std.c.windows.windows, making only those elements of the C standard that we
need in std.c.
3. Perhaps we should consider moving away fron the one-module-per-OS style
of organization; we could continue to have these blanket modules, but they
would really just be importing submodules that would contain organized
definitions, types, and anything else OS-specific.
What do you all think?

Have you checked out Ares? As was mentioned by others in prior posts, it
doesn't look like Phobos will change much, even in organization due to
the massive time constraints of it's maintainer. Ares, on the other
hand, was designed to be the bases for an improved structural orgranization.
-JJR

Since there's been some discussion on phobos's structure, I figured I'd
add in my $0.02 in a few suggestions:
1. move non-essential modules in to the etc tree, including but not
limited to things like std.recls and std.zlib (there is already an
etc.c.zlib it seems).
2. move all os-specific code out of std, and create a 'sys' tree
specifically for this kind of thing; thus, sys.windows.windows would
replace std.c.windows.windows, making only those elements of the C
standard that we need in std.c.
3. Perhaps we should consider moving away fron the one-module-per-OS
style of organization; we could continue to have these blanket modules,
but they would really just be importing submodules that would contain
organized definitions, types, and anything else OS-specific.
What do you all think?

Have you checked out Ares? As was mentioned by others in prior posts, it
doesn't look like Phobos will change much, even in organization due to the
massive time constraints of it's maintainer. Ares, on the other hand, was
designed to be the bases for an improved structural orgranization.

The thing that gets me is, we have all these different libraries doing a
bunchof things, with a good amount of overlap. If we established a process
by which the maintinence of phobos was not entirely Walter's job, or at
least less for him to do, we could then achieve a good "standard" library.
I believe the aim of a standard library is truely to be that: standard
across many different applications, and as such we should try to fold as
much of the duplicate stuff we feel should be folded.

Since there's been some discussion on phobos's structure, I figured I'd
add in my $0.02 in a few suggestions:
1. move non-essential modules in to the etc tree, including but not
limited to things like std.recls and std.zlib (there is already an
etc.c.zlib it seems).
2. move all os-specific code out of std, and create a 'sys' tree
specifically for this kind of thing; thus, sys.windows.windows would
replace std.c.windows.windows, making only those elements of the C
standard that we need in std.c.
3. Perhaps we should consider moving away fron the one-module-per-OS
style of organization; we could continue to have these blanket modules,
but they would really just be importing submodules that would contain
organized definitions, types, and anything else OS-specific.
What do you all think?

Have you checked out Ares? As was mentioned by others in prior posts, it
doesn't look like Phobos will change much, even in organization due to the
massive time constraints of it's maintainer. Ares, on the other hand, was
designed to be the bases for an improved structural orgranization.

The thing that gets me is, we have all these different libraries doing a
bunchof things, with a good amount of overlap. If we established a process
by which the maintinence of phobos was not entirely Walter's job, or at
least less for him to do, we could then achieve a good "standard" library.
I believe the aim of a standard library is truely to be that: standard
across many different applications, and as such we should try to fold as
much of the duplicate stuff we feel should be folded.

I totally agree. If the maintenance work was distributed somehow,
somebody would certainly clear up the module hierarchy and the Phobos
documentation. It looks kind of crap now.
I know Ares and Mango are good alternatives, but there's no real use for
them as long as all the redundant Phobos stuff is statically linked.
Although you say that DMD uses a lot of Phobos code for internal
structures, that's not completely true. There are several modules (e.g.
recls) that are not used. I can't believe it's impossible to modularize
the Phobos more.

The thing that gets me is, we have all these different libraries doing
a bunchof things, with a good amount of overlap. If we established a
process by which the maintinence of phobos was not entirely Walter's
job, or at least less for him to do, we could then achieve a good
"standard" library.

Personally, I don't think this will happen if people want to wait for
Walter's permission. That discussion has been on and off for years, and
it never went anywhere. Thus the existence of Ares. If the Ares
project takes off then Walter can always say "well that's cool, mind if
I use it?" and if it doesn't then it's no bother to him. The
alternative would mean a lot of up-front work for Walter to sort out a
community effort that may not go anywhere.

I know Ares and Mango are good alternatives, but there's no real use for
them as long as all the redundant Phobos stuff is statically linked.
Although you say that DMD uses a lot of Phobos code for internal
structures, that's not completely true. There are several modules (e.g.
recls) that are not used. I can't believe it's impossible to modularize
the Phobos more.

The redundant stuff isn't a part of Ares, and Mango is mostly an I/O
library. Give it a try. One of the reasons things started so slowly
with Ares is that I wanted to make sure the low-level design was clean
and as modular as possible. Ideally, beyond the essential core
components, everything else will be pluggable. As of now though, the
essential core components are pretty much all Ares has :-)
Sean