> 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.

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."
> 
> In my opinion, the greatest value Java and C# bring over C++ is not any 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.
> 
> Given that D doesn't have nearly the resources put into it as Java or C#, I 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 
> 
> 

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.

> "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."

!

> In my opinion, the greatest value Java and C# bring over C++ is not any 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.)

> Given that D doesn't have nearly the resources put into it as Java or C#, I 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.

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)

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!

> 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".

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)

:-)

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