www.digitalmars.com         C & C++   DMDScript  

digitalmars.D - Phobos namespace pollution

reply "David Barrett" <dbarrett quinthar.com> writes:
Generally, I think Phobos has picked a good abstraction level (threads, 
sockets, files, etc.).  It also has some excellent additional functionality 
(base64, utf, zlib, etc.).  But some of the modules -- while cool and 
useful -- don't strike me as universal (recls, uri, zip, etc.).  I'm 
concerned that Phobos will fracture, devolving from "universal, core 
functionality with rock-solid support" to "a collection of useful, albeit 
diverse functionality with varying support depending on the author".  Does 
anyone else share this concern?  Might we add a seventh rule to the "Phobos 
Philosophy", phrased something like:

"No special-purpose modules.  Don't add modules to Phobos that accomplish 
specific, high-level functions.  Rather, Phobos is reserved for modules that 
provide universal, low-level functionality that almost all applications 
require, irrespective of problem domain.  Phobos modules are supported with 
a priority equal to the compiler itself.  The namespace is big.  Use it."


particular language feature, but a well-supported, well-defined platform on 
which to build applications.  For example, virtually all Java programmers 
use the same core classes for strings, files, threads, sockets, etc.  This 
vastly reduces the learning curve for integrating a new developer into your 
team, as well as reduces the "design space" of options to consider when 
creating a new application.


think we need to be extremely disciplined about putting only the fewest, 
most critical features into Phobos, and then supporting them to the best of 
our ability.  Thus don't put anything in that we can't afford to make as 
rock-solid as the compiler itself.

After a quick glance, I'd recommend reorganizing Phobos as follows:

Keep little more than a hardware abstraction layer in 'std', and maintain at 
the highest priority
- std.compiler - Information about the D compiler implementation.
- std.ctype - Simple character classification
- std.file - Basic file operations like read, write, append.
- std.gc - Control the garbage collector.
- std.intrinsic - Compiler built in intrinsic functions
- std.math - Include all the usual math functions like sin, cos, atan, etc.
- std.mmfile - Memory mapped files.
- object - The root class of the inheritance hierarchy
- std.outbuffer - Assemble data into an array of bytes
- std.process - Create/destroy threads.
- std.random - Random number generation.
- std.socket - Sockets.
- std.stdio - Standard I/O.
- std.stream - Stream I/O.
- std.stdint - Integral types for various purposes.
- std.string - Basic string operations not covered by array ops.
- std.system - Inquire about the CPU, operating system.
- std.thread - One per thread. Operations to do on a thread.
- std.utf - Encode and decode utf character encodings.

Move general purpose, frequently useful code into 'util', and maintain 
according to interest
- std.base64 - Encode/decode base64 format.
- std.conv - Conversion of strings to integers.
- std.date - Date and time functions. Support locales.
- std.format - Formatted conversions of values to strings.
- std.md5 - Compute MD5 digests.
- std.path - Manipulate file names, path names, etc.
- std.regexp - The usual regular expression functions.
- std.socketstream - Stream for a blocking, connected Socket.
- std.uri - Encode and decode Uniform Resource Identifiers (URIs).
- std.zlib - Compression / Decompression of data.

Move high-level, single purpose modules into "misc", and leave to authors to 
maintain
- std.recls - Recursively search file system and (currently Windows only) 
FTP sites.
- std.zip - Read/write zip archives.

Oh, and finally, I'd recommend ditching the name "Phobos" and just calling 
it "the D standard library".  By assigning it a separate name, we treat it 
as separate entity, divorced from the "official D development package".

-david
Mar 28 2005
next sibling parent reply Trevor Parscal <Trevor_member pathlink.com> writes:
I would really like to agree with this post.. 

However, I suggest organizing the "Phobos" library differently...

object - No Complaints...
std    - This is good too...
compiler  - Keep the compiler stuff here...
intrinsic - Not like anything else is going to ever need this symbol.
string    - Move EVERYTHING that has to do with working with
strings in here. if you want the whole thing, use
std.string, if you want less, include them individually.
convert - Yes, I think we should use all 7 letters of the word
convert here... Why not? We used all 8 of compiler?
Are we saving people time, or making things easy to
understand? Honestly, this gets on my nerves.
test    - What's in here? C TypeDefs? No, they are tests...
Tests on characters. Yes I get it. Character TYPE.
But this is lame. Put all the character and string
tests in here, and move toupper and tolower to the
convert section.
format  - Perfect place for functions that format strings.
path    - Aren't these functions all just more string functions?
But move those matching functions to test, and make
them more general. C'mon, those are usefull for other
stuff, not just file names.
regexp  - I won't compain about the name, its pretty normal to call
it this, but this one still bothers me.
crypt   - This gets the contents of base64 and md5. Maybe even sub
set them as sub modules. Think ahead. How many algorithms
are there? Don't crowd the namespace.
uri     - Seems like a good place for these too.
utf
int  - I'm sorry, but std.stdint is as bad as Windows 2000's boot
message saying "Built on NT Technology"... (NT = New Technology)
math - First off, move the random stuff here too. Why wouldn't you?
Stop trying to make D like C, only.. kinda different!!
file - No need to change this. I love it here!
mmfile - If it's gonna throw a std.file.FileException, put it in
std.file...
search - recls is a bad name. This name is more universal, and we
can expand the module in the future to include other search
tools for files and folders.
buffer - outbuffer is too specific a name for something so usefull.
date   - This should stay here. What could be more universal?

net    - This is where network stuff should be.
socket - See how this tucks in nicely... As we get more networking
modules, put them in net too.
stream - This should be in socket. Let the compiler get rid
of what we don't use, and keep names clean. Besides,
as more socket helpers come, put them socket too.
Leave these...
gc
stream
system
process
thread

Remove these...
zlib  - This is a wrapper... Don't put it in the standard library namespace.
zip   - This is a good use of zlib, but, making the std library dependent on
zlib? Make a new library called compress or something and put the
old zlib interface in there, as well as other tools like this. Just
keep it out of the standard library...

And yes, Phobos, is a bad name. why do we access it as std. in actual code, and
call it phobos otherwise? Look, I love giving things cute names, but as a
usability consultant, I know that cute names are for marketing, and when they
dtract from the ability to unserstand what is going on, in this case the
relation of phobos and D, they are a VERY bad thing. I also have noticed the
devvelopment of other standard libraries for D with other cute names. To really
set the "Phobos" library apart as the one that is the native, D Standard
Library, we should call it nothing more than just that. The "D Standard Library"

Let me know what you think... I know my opinions are drastically different in
some ways to the original layout, but sometimes an outside perspective can
really help to clean up something that was made as you went like D obviously
was.

Thanks,
Trevor Parscal
www.trevorparscal.com
Mar 28 2005
parent reply Trevor Parscal <Trevor_member pathlink.com> writes:
I would really like to agree with this post.. 

However, I suggest organizing the "Phobos" library differently...
--------------------------------------------------------------------------------
object - No Complaints...

std.compiler - Keep the compiler stuff here...

std.intrinsic - Not like anything else is going to ever need this symbol.

std.string - Move EVERYTHING that has to do with working with strings in here.
if you want the whole thing, use std.string, if you want less, include them
individually.

std.string.convert - Yes, I think we should use all 7 letters of the word
convert here... Why not? We used all 8 of compiler?
Are we saving people time, or making things easy to
understand? Honestly, this gets on my nerves.

std.string.test - What's in here? C TypeDefs? No, they are tests... Tests on
characters. Yes I get it. Character TYPE. But this is lame. Put all the
character and string tests in here, and move toupper and tolower to the convert
section.

std.string.format - Perfect place for functions that format strings.

std.string.path - Aren't these functions all just more string functions? But
move those matching functions to test, and make them more general. C'mon, those
are usefull for other stuff, not just file names.

std.string.regexp  - I won't compain about the name, its pretty normal to call
it this, but this one still bothers me.

std.string.crypt - This gets the contents of base64 and md5. Maybe even sub set
them as sub modules. Think ahead. How many algorithms are there? Don't crowd the
namespace.

std.string.uri - Seems like a good place for these too.
std.string.utf

std.int - I'm sorry, but std.stdint is as bad as Windows 2000's boot message
saying "Built on NT Technology"... (NT = New Technology)

std.math - First off, move the random stuff here too. Why wouldn't you? Stop
trying to make D like C, only.. kinda different!!

std.file - No need to change this. I love it here!

std.file.mm - If it's gonna throw a std.file.FileException, put it in
std.file...

std.file.search - recls is a bad name. This name is more universal, and we can
expand the module in the future to include other search tools for files and
folders.

std.buffer - outbuffer is too specific a name for something so usefull.

std.date   - This should stay here. What could be more universal?

std.net    - This is where network stuff should be.

std.net.socket - See how this tucks in nicely... As we get more networking
modules, put them in net too.

std.net.socket.stream - This should be in socket. Let the compiler get rid
of what we don't use, and keep names clean. Besides,
as more socket helpers come, put them socket too.

Leave these...
std.gc
std.stream
std.system
std.process
std.thread

Remove these...
std.zlib  - This is a wrapper... Don't put it in the standard library namespace.

std.zip   - This is a good use of zlib, but, making the std library dependent on
zlib? Make a new library called compress or something and put the
old zlib interface in there, as well as other tools like this. Just
keep it out of the standard library...

And yes, Phobos, is a bad name. why do we access it as std. in actual code, and
call it phobos otherwise? Look, I love giving things cute names, but as a
usability consultant, I know that cute names are for marketing, and when they
dtract from the ability to unserstand what is going on, in this case the
relation of phobos and D, they are a VERY bad thing. I also have noticed the
devvelopment of other standard libraries for D with other cute names. To really
set the "Phobos" library apart as the one that is the native, D Standard
Library, we should call it nothing more than just that. The "D Standard Library"

Let me know what you think... I know my opinions are drastically different in
some ways to the original layout, but sometimes an outside perspective can
really help to clean up something that was made as you went like D obviously
was.

Thanks,
Trevor Parscal
www.trevorparscal.com
Mar 28 2005
next sibling parent reply =?ISO-8859-1?Q?Anders_F_Bj=F6rklund?= <afb algonet.se> writes:
Trevor Parscal wrote:


 std.string.regexp  - I won't compain about the name, its pretty normal to call
 it this, but this one still bothers me.


"standard.regularexpression" becomes kinda awkward :-)


 std.string.crypt - This gets the contents of base64 and md5. Maybe even sub set
 them as sub modules. Think ahead. How many algorithms are there? Don't crowd
the
 namespace.


Although, base64 and md5 are not encryptions ? ("crypt")
And neither of them has much to do with strings, either ?

Grouping them is OK, just not as "string" or "crypt"...

There is also "crc", which kinda got lost ? (crc32.d)
Most likely, it also belongs in a crc32 module here.


 std.int - I'm sorry, but std.stdint is as bad as Windows 2000's boot message
 saying "Built on NT Technology"... (NT = New Technology)


stdint.h is a portability wrapper, stdint.d is the same.
So the naming for this particular module is due to legacy
interfacing with C, same as std.c.stdio and std.c.stdlib

But the same goes for std.stdio, of course... ("std.io" ?)

See earlier posts, on the same topic. Here is one sample thread:
http://www.digitalmars.com/d/archives/digitalmars/D/6450.html


 std.zlib  - This is a wrapper... Don't put it in the standard library
namespace.


It belongs in "etc.zlib" (since it calls upon etc.c.zlib...)


 std.zip   - This is a good use of zlib, but, making the std library dependent
on
 zlib? Make a new library called compress or something and put the
 old zlib interface in there, as well as other tools like this. Just
 keep it out of the standard library...


And if anything, it probably also should go into etc instead.

--anders
Mar 28 2005
parent reply Trevor Parscal <Trevor_member pathlink.com> writes:
The crypt thing, I agree. sorry, it's late. I am not thinking straight. but
grouping them is a good idea.

etc... As long as it's clean. That works..

Othwerwise, you get my idea. Clean it up. Names of things should have a strong
meaning, not just, "Oh, now that you explain it, that kinda makes sense.."

Thanks
Trevor Parscal
www.trevorparscal.com
Mar 28 2005
parent reply =?ISO-8859-1?Q?Anders_F_Bj=F6rklund?= <afb algonet.se> writes:
Trevor Parscal wrote:


 Othwerwise, you get my idea. Clean it up. Names of things should have a strong
 meaning, not just, "Oh, now that you explain it, that kinda makes sense.."


Most of the names have history reasons, since D has a strong C legacy.

Whether or not they need to be "cleaned up" for use with D, seems to be
a constant source of argument over the five years that D has existed...

--anders
Mar 28 2005
parent reply Benjamin Herr <ben 0x539.de> writes:
Anders F Björklund wrote:

 Most of the names have history reasons, since D has a strong C legacy.


I thought D was supposed to be fun because it does not have to be 
compatible with C(++)?


 Whether or not they need to be "cleaned up" for use with D, seems to be
 a constant source of argument over the five years that D has existed...


Geez, you would think people would stop asking for reforms after being 
told off for five years. :D


 --anders


Benjamin
Mar 28 2005
parent =?ISO-8859-1?Q?Anders_F_Bj=F6rklund?= <afb algonet.se> writes:
Benjamin Herr wrote:


 Most of the names have history reasons, since D has a strong C legacy.


 
 I thought D was supposed to be fun because it does not have to be 
 compatible with C(++)?


It is (fun). Besides, who said C was boring? C++ on the other hand...

I just meant the D naming follows a C-like manner? Thus, "std.stdio".


 Geez, you would think people would stop asking for reforms after being 
 told off for five years. :D


I wouldn't know, as I've only followed for it like one (i.e. since GDC)

Stopped asking somewhere after the futile "boolean" discussions earlier.

--anders
Mar 28 2005
prev sibling parent "Ben Hinkle" <bhinkle mathworks.com> writes:
 std.string - Move EVERYTHING that has to do with working with strings in 
 here.
 if you want the whole thing, use std.string, if you want less, include 
 them
 individually.


I agree std.conv should become std.convert (and probably "crypt" shoudl 
change) but the other packages seem pretty self-explanatory without needing 
the "string" in the package name. If we start clashing within std package 
then sub-packages would make sense. Also since std.string would be a 
directory to contain all the std.string.* packages one could not write 
"import std.string;".


 std.int - I'm sorry, but std.stdint is as bad as Windows 2000's boot 
 message
 saying "Built on NT Technology"... (NT = New Technology)


Both std.stdint and std.stdio are ugly but recognizable. I don't know if 
keywords are allowed as package names.


 std.math - First off, move the random stuff here too. Why wouldn't you? 
 Stop
 trying to make D like C, only.. kinda different!!

 std.file - No need to change this. I love it here!

 std.file.mm - If it's gonna throw a std.file.FileException, put it in
 std.file...


Package vs module clash. Is std.file a package or module? It can't be both.


 std.net.socket - See how this tucks in nicely... As we get more networking
 modules, put them in net too.

 std.net.socket.stream - This should be in socket. Let the compiler get rid
 of what we don't use, and keep names clean. Besides,
 as more socket helpers come, put them socket too.


Unfortunately looks like another package/module clash.


 And yes, Phobos, is a bad name. why do we access it as std. in actual 
 code, and
 call it phobos otherwise? Look, I love giving things cute names, but as a
 usability consultant, I know that cute names are for marketing, and when 
 they
 dtract from the ability to unserstand what is going on, in this case the
 relation of phobos and D, they are a VERY bad thing. I also have noticed 
 the
 devvelopment of other standard libraries for D with other cute names. To 
 really
 set the "Phobos" library apart as the one that is the native, D Standard
 Library, we should call it nothing more than just that. The "D Standard 
 Library"


I actually prefer Phobos over D Standard Library because it is easier to say 
and write. I wish C/C++/Java had a similar easy-to-say name. Let's not go 
down J2SE etc.
Mar 28 2005
prev sibling next sibling parent =?ISO-8859-1?Q?Anders_F_Bj=F6rklund?= <afb algonet.se> writes:
David Barrett wrote:


 I'm  concerned that Phobos will fracture, devolving from "universal, core 
 functionality with rock-solid support" to "a collection of useful, albeit 
 diverse functionality with varying support depending on the author".  Does 
 anyone else share this concern? 


Considering that both D compilers now has their own version of Phobos,
I'd say it's a valid concern. And the recls support has been described
by the author of that particular package as... well, not rock-solid ?

There is more than one high-end alternative to Phobos, so the more of
a basic runtime library that it could become - the better (just IMHO).


The main objections against Phobos boils down to something like:
- any and all changes to it taking ages to appear (the "Cathedral")
- lack of object-orientation (usually the lack of a "class String")
- runtime library being tied to the DMD compiler (i.e. not portable)
- runtime library being tied to standard library (e.g. GC, callbacks)
- missing lib features, like a template library or a widget toolkit

There has been different "solutions" to this: Deimos, Dool, and so on.


I think the best would probably be if Phobos was split in three parts,
* lowlevel like _d_assert, object and std.gc (std.c too, probably ?)
* regular D standard library modules : std.stdio, std.utf, etc...
* highlevel add-on C libraries: recls, zlib, libSDL, OpenGL, etc...

At least on a "philosophical" level, it does not have to be visible ?



 After a quick glance, I'd recommend reorganizing Phobos as follows:


For some reason, you left out std.c.math, std.c.stdio and std.c.stdlib ?
Phobos still uses the C standard library to implement a lot of features.

There is also the veritable zoo of std.c.operatingsystemdujour modules,
which I can understand that you didn't want to mention either... :-)

But both of these are part of Phobos.


 Keep little more than a hardware abstraction layer in 'std', and maintain at 
 the highest priority
 - std.compiler - Information about the D compiler implementation.


This file is just a stub at the moment, hardcoded as "DMD 0.0"...


 - object - The root class of the inheritance hierarchy


As you might be aware, this module now holds Exception and Error too.
(well, and "printf" and "bool" and the kitchen sink too - but anyway)


 - std.stdio - Standard I/O.


Currently lacking all forms of input, making it the "Standard O" :-)
(but code to implement readf and std.unformat have been submitted...)


 - std.stdint - Integral types for various purposes.


Mostly converting legacy C code, not for use with new D code...
(I think that it *could* be used, but I suggested std.stdutf too)


 - std.system - Inquire about the CPU, operating system.


Again, this module is just stub. Hardcoded as "Windows NT 4.0"...


 - std.zlib - Compression / Decompression of data.


Most of the functionality in this one comes from etc.c.zlib
(which in turn is a straight-forward translation of zlib.h)

Preferably, Phobos should use the system version of zlib -
and just use the bundled static zlib version as a fallback... ?

And then it could be moved to "std.c.zlib instead", as well.


 Move high-level, single purpose modules into "misc", and leave to authors to 
 maintain


I think the chosen name for this hierarchy is already "etc",
and has been partly taken up by the Deimos project already...

http://dsource.org/projects/deimos/

Both recls and zlib also have different licensing than Phobos does,
if you disregard the handful of std modules with different licenss.


 - std.recls - Recursively search file system and (currently Windows only) 
 FTP sites.


The (C++) implementation of this module being found under etc already...

I know that std.recls itself has a couple of version(GNU) patches, too.


 - std.zip - Read/write zip archives.


std.zip is not that bad, it's std.zlib that has the etc dependancies...

In the current implementation, they should move to etc.zip and etd.zlib


 Oh, and finally, I'd recommend ditching the name "Phobos" and just calling 
 it "the D standard library".  By assigning it a separate name, we treat it 
 as separate entity, divorced from the "official D development package".


I think the "D Runtime Library" is already the official name for it ?

http://www.digitalmars.com/d/phobos.html

 Phobos is the standard runtime library that comes with the D language compiler.


But it would be nice if:
1) The Phobos library source code could be shared between DMD and GDC
2) The "D runtime library" and the "D standard library" could be split
3) recls and zlib could move from the "std" to the "etc" hierarchy

I can contribute my adapations of SDL 1.2.8 and OpenGL 1.2.1 headers as
etc.c.sdl and etc.c.opengl, if wanted... ? (Different from Derelict's,
in that it doesn't use function pointers - just a C header translation)

--anders
Mar 28 2005
prev sibling next sibling parent reply =?windows-1252?Q?Anders_F_Bj=F6rklund?= <afb algonet.se> writes:
David Barrett wrote:


 After a quick glance, I'd recommend reorganizing Phobos as follows:


You would also want to visit both Dsource and the Wiki4D, first ?

http://www.prowiki.org/wiki4d/wiki.cgi?StandardLibrary

 Every now and then it is said that the Phobos library (the
 current standard library) is preliminary and needs a redesign.


It's probably the place to discuss any Phobos re-engineering,
at least if you want the Bazaar rather than the Cathedral... ;-)
(see http://www.catb.org/~esr/writings/cathedral-bazaar/)


MAJOR D LIBRARIES:

Phobos (http://www.digitalmars.com/d/phobos.html)
------

"Phobos* is the standard runtime library that comes with the D
language compiler." (i.e. DMD, but has also been patched for GDC)
With a few exceptions, it is consisting of the std and std.c trees.


Deimos (http://www.dsource.org/forums/viewforum.php?f=26)
------
While the "std" tree is Phobos, the "etc" tree is called Deimos*.
Right now it mostly hosts etc.bigint and etc.unicode, which are
next to useless due to licensing and replaced by GNU MP and ICU.

Ares (http://dsource.org/forums/viewforum.php?f=31)
----
You should also check out "Ares - the second coming of Phobos":
There is some D code at: http://www.home.f4.ca/sean/d/ares.zip.
This project is about "fixing" the problems with the std tree...


Mango (http://www.dsource.org/projects/mango/)
-----
Ares also "includes" ports of ICU and Log4J, from Kris's Mango Tree -
there are standalone versions of those, without the rest of mango:
mango.icu and mango.log is the module namespace being used there)

Dool (http://dool.sourceforge.net/)
----
Another Phobos replacement project is Ant's Object Oriented Library,
with dool.io, dool.sql and the venerable "dool.String" class too...
(Ant, if you're lurking - can't String be made immutable? Please?)


None of these, except for the Phobos library that is,
are "official D" libraries, or from Digital Mars™...

And until "D 1.0" is finalized/released, it is kinda hard to tell
what went into the standard library and what instead became addons ?

--anders

* PS. Here is the background story of the somewhat odd library naming:

Walter Bright said: (note that the D is still red, just like Mars is)


 I tried calling D the "mars" language initially, but everyone kept calling
 it D. There's just no point in trying to swim up Niagra Falls <g>, so D it
 is. As you said, it's short, sweet, and to the point.


(being archived under http://www.digitalmars.com/d/archives/15721.html)

And Arcane Jill wrote, just before disappearing into the Great Unknown:


 The runtime library which comes with the D compiler is called Phobos,
 named after one of the moons of Mars. Deimos (named after the _other_ of
 Mars's moons) is the unofficial but commonly used name for a body of
 code which is provided by contributors to supplement the modules
 provided by Phobos.


(from http://svn.dsource.org/svn/projects/deimos/trunk/docs/intro.html)
Mar 28 2005
parent reply Georg Wrede <georg.wrede nospam.org> writes:
Anders F Björklund wrote:

 David Barrett wrote:

 Every now and then it is said that the Phobos library (the
 current standard library) is preliminary and needs a redesign.




LOL! (A friendly, affectionate giggle. Not offensive.)

Anyhow, to quote from above "(the current standard library)".


 MAJOR D LIBRARIES:


.....

 None of these, except for the Phobos library that is,
 are "official D" libraries, or from Digital Mars™...


Hmm. Actually, the _only_ thing that IMHO suggests keeping the name 
Phobos, is, if we want to remind people that we are still keeping open 
the option of _maybe_choosing_something_else_ as the standard library 
for DMD 1.0.

If this is not the case, then we should bury the name Phobos today.
Mar 28 2005
parent reply =?UTF-8?B?QW5kZXJzIEYgQmrDtnJrbHVuZA==?= <afb algonet.se> writes:
Georg Wrede wrote:


 Hmm. Actually, the _only_ thing that IMHO suggests keeping the name 
 Phobos, is, if we want to remind people that we are still keeping open 
 the option of _maybe_choosing_something_else_ as the standard library 
 for DMD 1.0.
 
 If this is not the case, then we should bury the name Phobos today.


I think it's kinda neat to have a std standard library named "Fear".
And then you have a etc community library named "Panic". Hilarious ?

AFAIK; Mars is the Roman name, and Phobos and Deimos are both Greek
and the sons of the war god Ares (recently revived as a std rewrite)
There is also plenty of room here for a third library, named: "Enyo"
(goddess of War, Blood and Violence - one of the best friends of Eris*)

Everyone elses code name's is some lame old animal, like "Tiger"...
(being the code name *both* for Mac OS X 10.4, *and* JDK 1.5 too !)


You also get NASA excerpts like:

 It is believed that Phobos is gradually losing its orbit around Mars and
 that, in about 100 million years, the moon will either be torn apart by
 Mars's stronger gravity, shattering into millions of fragments and
 forming a ring system around the planets similar to Saturn's, or the
 moon will hit the planet. This will leave a huge crater on the planet's
 surface.


Two likely scenarios of the future of D, right there in astronomy. :-)


It's not like you ever need to know it is called Phobos, unless you
look under the hood and see it is linking with -lphobos ? It's "std".

Guess it could be renamed to something boring, like libdrt.a ? <yawn>
As long as it is not called anything "Enterprise", or "." or "i"...

--anders

* PS. Hail Eris! All Hail Discordia!
Mar 28 2005
parent "Ben Hinkle" <bhinkle mathworks.com> writes:
 Guess it could be renamed to something boring, like libdrt.a ? <yawn>


hmm. how about the "D language basic run time library" shortened to dlbrt 
and pronounced "dilbert".
Mar 28 2005
prev sibling next sibling parent reply Georg Wrede <georg.wrede nospam.org> writes:
Pardon, all Regular posters, but I'm taking the liberty to comment on 
this, althoug there already is a cascade of discussion invoked by this. 
Let's just assume I read this a bit earlier. :-)

The beginning of this post reminded me of what we could achieve if 
Phobos was actually put on Sourceforge. As Linus Torvalds said "Given 
enough eyes, _any_ problem gets shallow."

It is this kind of posts and suggestions, that really move Phobos 
forward. AND, I hope everyone sees that this post was the result of 
carefult thinking -- the kind new and able posters do (as compared to us 
"regulars" who (sadly) often post off-hand). All the content below 
should therefore be considered carefully.

Another thing, the author is correct in his opinion about the name 
Phobos. (Now, (Walter, and others,) our problem is that we're so used to 
the name Phobos, that none of the regulars probably would ever have come 
up with the thought of renaming it.) (Not to mention the affective 
attitude we have towards the name -- it is, after all, the name of Mars' 
moon, and as such probably a pet of many of us.)

The problem, as stated below, is valid and important. (But I understand 
a certain reluctance to start discussing the name, like Euphoria 
language has about its name -- which makes a huge disservice to 
spreading the language, and still will get changed only over Craig's 
dead body.)

A brand for what is the standard library, is misleading. There should 
not be one. While the name may have served a purpose several years ago, 
today I can not see a single pro, only a lot of cons.

-----------------

Reorganising Phobos as suggested here, would bring tangible benefits. 
Since Walter has other things to do (and should!), such a refactoring 
would naturally fall to the guys "at Sourceforge".

David Barrett wrote:

 Generally, I think Phobos has picked a good abstraction level (threads, 
 sockets, files, etc.).  It also has some excellent additional functionality 
 (base64, utf, zlib, etc.).  But some of the modules -- while cool and 
 useful -- don't strike me as universal (recls, uri, zip, etc.).  I'm 
 concerned that Phobos will fracture, devolving from "universal, core 
 functionality with rock-solid support" to "a collection of useful, albeit 
 diverse functionality with varying support depending on the author".  Does 
 anyone else share this concern?  Might we add a seventh rule to the "Phobos 
 Philosophy", phrased something like:
 
 "No special-purpose modules.  Don't add modules to Phobos that accomplish 
 specific, high-level functions.  Rather, Phobos is reserved for modules that 
 provide universal, low-level functionality that almost all applications 
 require, irrespective of problem domain.  Phobos modules are supported with 
 a priority equal to the compiler itself.  The namespace is big.  Use it."
 

 particular language feature, but a well-supported, well-defined platform on 
 which to build applications.  For example, virtually all Java programmers 
 use the same core classes for strings, files, threads, sockets, etc.  This 
 vastly reduces the learning curve for integrating a new developer into your 
 team, as well as reduces the "design space" of options to consider when 
 creating a new application.
 

 think we need to be extremely disciplined about putting only the fewest, 
 most critical features into Phobos, and then supporting them to the best of 
 our ability.  Thus don't put anything in that we can't afford to make as 
 rock-solid as the compiler itself.
 
 After a quick glance, I'd recommend reorganizing Phobos as follows:
 
 Keep little more than a hardware abstraction layer in 'std', and maintain at 
 the highest priority
 - std.compiler - Information about the D compiler implementation.
 - std.ctype - Simple character classification
 - std.file - Basic file operations like read, write, append.
 - std.gc - Control the garbage collector.
 - std.intrinsic - Compiler built in intrinsic functions
 - std.math - Include all the usual math functions like sin, cos, atan, etc.
 - std.mmfile - Memory mapped files.
 - object - The root class of the inheritance hierarchy
 - std.outbuffer - Assemble data into an array of bytes
 - std.process - Create/destroy threads.
 - std.random - Random number generation.
 - std.socket - Sockets.
 - std.stdio - Standard I/O.
 - std.stream - Stream I/O.
 - std.stdint - Integral types for various purposes.
 - std.string - Basic string operations not covered by array ops.
 - std.system - Inquire about the CPU, operating system.
 - std.thread - One per thread. Operations to do on a thread.
 - std.utf - Encode and decode utf character encodings.
 
 Move general purpose, frequently useful code into 'util', and maintain 
 according to interest
 - std.base64 - Encode/decode base64 format.
 - std.conv - Conversion of strings to integers.
 - std.date - Date and time functions. Support locales.
 - std.format - Formatted conversions of values to strings.
 - std.md5 - Compute MD5 digests.
 - std.path - Manipulate file names, path names, etc.
 - std.regexp - The usual regular expression functions.
 - std.socketstream - Stream for a blocking, connected Socket.
 - std.uri - Encode and decode Uniform Resource Identifiers (URIs).
 - std.zlib - Compression / Decompression of data.
 
 Move high-level, single purpose modules into "misc", and leave to authors to 
 maintain
 - std.recls - Recursively search file system and (currently Windows only) 
 FTP sites.
 - std.zip - Read/write zip archives.
 
 Oh, and finally, I'd recommend ditching the name "Phobos" and just calling 
 it "the D standard library".  By assigning it a separate name, we treat it 
 as separate entity, divorced from the "official D development package".
 
 -david
Mar 28 2005
parent reply =?ISO-8859-1?Q?Anders_F_Bj=F6rklund?= <afb algonet.se> writes:
Georg Wrede wrote:


 The beginning of this post reminded me of what we could achieve if 
 Phobos was actually put on Sourceforge. As Linus Torvalds said "Given 
 enough eyes, _any_ problem gets shallow."


Actually it was Eric S. Raymond that wrote:
"Given enough eyeballs, all bugs are shallow"
He just dubbed it as: Linus's Law (= inspired by)

* Release Early, Release Often
http://www.catb.org/~esr/writings/cathedral-bazaar/cathedral-bazaar/ar01s04.html



 Since Walter has other things to do (and should!), such a refactoring 
 would naturally fall to the guys "at Sourceforge".


Phobos (well, almost all of it) have now had the
licensing issues cleared up, to allow Open Source.
But the "new stuff" is at Dsource, not SourceForge.

I don't see it makes a difference where the project
is hosted ? The main issue is whether development is
done by a single entity, or by "us" as a community ?

And Walter has already stated he accepts help with it,
it just hasn't been formalized *how* it is going to work...
Sooner or later, it will need to have such things decided.


It's just a question of whether it'll be in "D 1.0", or not ?

As in: will D be released with a less than perfect std lib,
and then have it reworked for a community release of "D 2.0" -
or will the release of D be delayed until the lib is perfect ?
(Having some timeframes set, would probably help to decide...)

Assume that one wants D *released* this year: 2005. Then what ?

I think it's more about bugfixing, than it is about refactoring...
(and, yes, this probably means the DTL and DWT have to wait too ?)
Detailed list at http://prowiki.org/wiki4d/wiki.cgi?HelpDProgress
(currently eagerly awaiting the next version of the GDC compiler)

--anders,
one of the "guys at SourceForge" (= hosted at)
Mar 28 2005
parent Georg Wrede <georg.wrede nospam.org> writes:
Anders F Björklund wrote:

 Georg Wrede wrote:
 

 The beginning of this post reminded me of what we could achieve if 
 Phobos was actually put on Sourceforge. As Linus Torvalds said "Given 
 enough eyes, _any_ problem gets shallow."


 
 Actually it was Eric S. Raymond that wrote:
 "Given enough eyeballs, all bugs are shallow"
 He just dubbed it as: Linus's Law (= inspired by)


Thanks! :-)


 Phobos (well, almost all of it) have now had the
 licensing issues cleared up, to allow Open Source.
 But the "new stuff" is at Dsource, not SourceForge.
 
 I don't see it makes a difference where the project
 is hosted ? The main issue is whether development is
 done by a single entity, or by "us" as a community ?


Correct!


 And Walter has already stated he accepts help with it,
 it just hasn't been formalized *how* it is going to work...
 Sooner or later, it will need to have such things decided.


This ought to be considered urgent.


 It's just a question of whether it'll be in "D 1.0", or not ?


Let's say we "knew" it's 2 months away. And let's say, that the ideas of 
the original poster were valid. Then we'd probably be able to do most of 
that stuff in those 2 months?


 As in: will D be released with a less than perfect std lib,
 and then have it reworked for a community release of "D 2.0" -


Ughhh, a bad dream.


 one of the "guys at SourceForge" (= hosted at)


:-)
Mar 28 2005
prev sibling next sibling parent Georg Wrede <georg.wrede nospam.org> writes:
 "No special-purpose modules.  Don't add modules to Phobos that accomplish 
 specific, high-level functions.  Rather, Phobos is reserved for modules that 
 provide universal, low-level functionality that almost all applications 
 require, irrespective of problem domain.  Phobos modules are supported with 
 a priority equal to the compiler itself.  The namespace is big.  Use it."


!



 particular language feature, but a well-supported, well-defined platform on 
 which to build applications.  For example, virtually all Java programmers 
 use the same core classes for strings, files, threads, sockets, etc.  This 
 vastly reduces the learning curve for integrating a new developer into your 
 team, as well as reduces the "design space" of options to consider when 
 creating a new application.


Obvious to all except us regulars. (Not because we're dumb, but because 
we're regulars.)



 think we need to be extremely disciplined about putting only the fewest, 
 most critical features into Phobos, and then supporting them to the best of 
 our ability.  Thus don't put anything in that we can't afford to make as 
 rock-solid as the compiler itself.
 
 After a quick glance, I'd recommend reorganizing Phobos as follows:
 
 Keep little more than a hardware abstraction layer in 'std', 


!


 and maintain at the highest priority
 - std.compiler - Information about the D compiler implementation.
 - std.ctype - Simple character classification
 - std.file - Basic file operations like read, write, append.
 - std.gc - Control the garbage collector.
 - std.intrinsic - Compiler built in intrinsic functions
 - std.math - Include all the usual math functions like sin, cos, atan, etc.
 - std.mmfile - Memory mapped files.
 - object - The root class of the inheritance hierarchy
 - std.outbuffer - Assemble data into an array of bytes
 - std.process - Create/destroy threads.
 - std.random - Random number generation.
 - std.socket - Sockets.
 - std.stdio - Standard I/O.
 - std.stream - Stream I/O.
 - std.stdint - Integral types for various purposes.
 - std.string - Basic string operations not covered by array ops.
 - std.system - Inquire about the CPU, operating system.
 - std.thread - One per thread. Operations to do on a thread.
 - std.utf - Encode and decode utf character encodings.


!


 Move general purpose, frequently useful code into 'util', and maintain 
 according to interest
 - std.base64 - Encode/decode base64 format.
 - std.conv - Conversion of strings to integers.
 - std.date - Date and time functions. Support locales.
 - std.format - Formatted conversions of values to strings.
 - std.md5 - Compute MD5 digests.
 - std.path - Manipulate file names, path names, etc.
 - std.regexp - The usual regular expression functions.
 - std.socketstream - Stream for a blocking, connected Socket.
 - std.uri - Encode and decode Uniform Resource Identifiers (URIs).
 - std.zlib - Compression / Decompression of data.


!


 Move high-level, single purpose modules into "misc", and leave to authors to 
 maintain
 - std.recls - Recursively search file system and (currently Windows only) 
 FTP sites.
 - std.zip - Read/write zip archives.


Now, that I've read the thread so far, this is yet another time when a 
seriously considered proposal get watered down. First everyone and his 
dog have to get their spoon in the soup, and then people start looking 
at each others' spoons, and their merits/defects. So the original, well 
thought out idea gets overshadowed.
Mar 28 2005
prev sibling parent Sean Kelly <sean f4.ca> writes:
This was the goal of Ares.  That is, to develop both the a reference
implementation and a spec for a "D Standard Library."  IMO Phobos doesn't fit
the bill for the reasons you mentioned, and it seemed easier to just go ahead
and create one than to try and get Walter's involvement when he's already quite
busy.  

It's worth noting that Phobos contains language support routines and the gc
code, neither of which I think fit in a standard library.  IMO the ideal
solution to this particular issue is to have the language support library, the
standard library, and the gc be independent units that interact minimally, and
then only in a well-defined manner.  This is pretty much where Ares stands now.
The design still needs some refinement, but Ares is a functional minimal lib for
D.


Sean
Mar 29 2005