www.digitalmars.com         C & C++   DMDScript  

digitalmars.D - proposal- reorganize and simplify phobos hierarchy somewhat

reply "Ameer Armaly" <ameer_armaly hotmail.com> writes:
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
Nov 22 2005
parent reply John Reimer <terminal.node gmail.com> writes:
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
Nov 22 2005
parent reply "Ameer Armaly" <ameer_armaly hotmail.com> writes:
"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
Nov 23 2005
parent reply =?ISO-8859-1?Q?Jari-Matti_M=E4kel=E4?= <jmjmak invalid_utu.fi> writes:
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.
Nov 23 2005
parent Sean Kelly <sean f4.ca> writes:
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
Nov 23 2005