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

Ameer Armaly wrote:
> 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

"John Reimer" <terminal.node@gmail.com> wrote in message news:dm0olo$hgv$1@digitaldaemon.com...
> Ameer Armaly wrote:
>> 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.
>
> -JJR

Ameer Armaly wrote:
> "John Reimer" <terminal.node@gmail.com> wrote in message news:dm0olo$hgv$1@digitaldaemon.com...
> 
>>Ameer Armaly wrote:
>>
>>>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.

Jari-Matti Mäkelä wrote:
> Ameer Armaly wrote:
>>
>> 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