It may be lacking in a lot of things, but I feel the fundamental problem is more a lack of cohesion, plus vague functional overlap in places. Other problems include the namespace pollution. For example, importing std.string almost inevitably leads to collisions of some kind. There was an example recently where the module-level ('C' style) toString() methods of std.string 'eliminated' a superclass toString() from being resolved. I think that's a problem. Some may not.

One way to resolve both sides is to ensure all module-level functions are within their own namespace. For example, Mango places such methods and singletons within a named struct, so one addresses them as (for example)

Code:

x = Tokenizers.LineScanner;

"LineScanner" is just not valid by itself, because it's too easy for such 'detached' names to collide with other 'detached' ones (in your code, or another library). The same applies to module-level enums ... things like that can quickly cause conflict that's rather unnecessary. This is similar to how Java, C# and others do it, e.g. System.println(...). Naturally, things that live within a class boundary are immune from this; it's only the 'C' style globally visible things that are questionable. Phobos has quite a bit of that, and it does cause problems (Mango ended up removing virtually all Phobos imports, purely due to these conflicts). This is about making the library unproblematic for a user.

Some things should be considered for removal: File is one that comes to mind. Another potential candidate for removal is Regex. Although I really like Walter's Regex, I think we'd be better off in the long run with a Unicode enabled version (such as from what AJ is working on). Perhaps Regex can be made wchar instead? Just ideas.

There's a number of additional things that I'd like to see in this libray, but I'll leave that for later.

So that anyone can easily see the current state of the standard library.

Furthermore, if you let anyone help but permit them to only "contract"
one item, it will prevent people from doing redundant work, but will let
people more easily get in touch with the contracted coder to help out.
Also, if a while goes by without any progress, that can easily be seen
by the last update.

People could also volunteer to pre-check library code at any updates to
see if it follows the standards with final verification being done by
the "committee" once it reaches 100? completion.

There's a number of additional things that I'd like to see in this libray, but I'll leave that for later.

Actually, I'd like to solicit you for your input, no matter how verbose. I would like to motion towards something resembling project milestones after all this, so the more the merrier!_________________-- !Eric.t.Anderton at gmail

There's a number of additional things that I'd like to see in this libray, but I'll leave that for later.

Actually, I'd like to solicit you for your input, no matter how verbose. I would like to motion towards something resembling project milestones after all this, so the more the merrier!

Okay then ... now, these are just ideas:

Firstly though, there's often a desire to add everything plus the kitchen-sink into a library. It's easy to go overboard, and hard to control it thereafter. One thing we should consider is "where to draw the line". You see, there's no requirement for just one standard lib ... if it makes sense to split them in segregated areas of responsibility, then so be it.

Let's start with Unicode. This is a tough one, because I'd love to see some basic functionality in the primary lib. After all, that's probably how people will be introduced to the D I18N abilities. A String class is what immediately springs to mind, and there's a well-designed one (IMO) in the stuff AJ will be porting. However, it might be a bit top-heavy for the primary lib. I'm secretly hoping that it may be feasible to split some basic functionality off into a "fundamental Unicode" String class, and add a bunch more bells and whistles in a derivative. These might live in seperate standard libs. I'm sure such "which side of the fence" questions will arise at various times.

Other things that might make it into the primary lib are the I18N message resources, and related message formatting. The date & time formatters from that project would be an awesome addition (especially since they will get used with IOStream readers/writers, and with user-presentation). I think there should be a library area (package prefix) specifically for a variety of such formatters/parsers/converters. That includes the usual int/float/string conversions currently in std.string.

Some basic HTTP functionality would be good. For example, a real URI class, perhaps an HTTP client, maybe some Cookie support? However, related APIs such as these might well be better off in their own isolated "Phoenix.http" library. This is what I'm getting at with the multiple standard libs thing.

IMO, the file-system stuff should be completely overhauled and isolated into the appropriate OO modules. I'm not talking about Streams; rather I'm talking about the "list files from here", "is that a directory?", "what size is this file?", "change the working directory to X" kind of stuff. Yes, you probably all know that's how Mango does it, but then so do many other libraries, because it seems to just work naturally.

Ben and Mike have some great functionality in their "DL Forever!" port. This may not suit everyone, but it's a prime candidate for another standard lib, if not the primary one. Maybe these other libs might be called extensions?

I don't think anyone should have to say this, but GUI support should not be in the standard lib. Nor should OpenGL or similar libraries. If it's not obvious why not, then let's discuss in a seperate topic.

The Bigint and other fine works in Deimos might well fit into the standard lib also; but it's a bit like the HTTP stuff, in that it's not for everyone. Certainly deserves to be in an extension lib, I think.

I just forgot two others ... uhhh?

That's probably enough to be going on with for now. I will note that I think it's really important to try and get these shipped as DLLs. Doing so will relieve some of the pressure regarding granularity but, more importantly, will permit the sharing of Objects between the primary library and subordinate ones. I cannot stress just how important that is ... moving the GC into a DLL is the first step. I suspect we'll need support from the compiler to make DLL-based libs work effectively.

Last edited by kris on Thu Aug 26, 2004 11:13 pm; edited 1 time in total

While I remember, I think this library should be OO. Phobos is pretty loose about this, with much of it implemented more like a traditional C library. I'm not knocking the latter per se, but D is meant to be an OO language, is it not? Further, the C-style global methods and so on (module level) do cause notable problems with namespace collisions.

kris brings up a good point: there should be a rule of thumb for what should not be covered as well.

I think so too, how broad should phoenix be ? And more important for me, how can we as users get these 'specialty' libs ( the fun ones ) ?

Someone on the NG referenced pythons (S)pecial (I)nterest (G)roups , theres also perl's (C)omprehensive(P)erl(A)rchive(N)etwork, I think a centralized repository is essential, will the DSLG be responsible for this also ? ( I vote yes , in which case you might have to rename it to (D)(P)heonix(G)roup or something... )

kris brings up a good point: there should be a rule of thumb for what should not be covered as well.

I think so too, how broad should phoenix be ? And more important for me, how can we as users get these 'specialty' libs ( the fun ones ) ?

Someone on the NG referenced pythons (S)pecial (I)nterest (G)roups , theres also perl's (C)omprehensive(P)erl(A)rchive(N)etwork, I think a centralized repository is essential, will the DSLG be responsible for this also ? ( I vote yes , in which case you might have to rename it to (D)(P)heonix(G)roup or something... )

One might also think of DSLG as the DSource Library Group

DSource, after all, is the home of the 'fun' libs also!

Last edited by kris on Thu Aug 26, 2004 11:40 pm; edited 1 time in total

While I remember, I think this library should be OO. Phobos is pretty loose about this, with much of it implemented more like a traditional C library. I'm not knocking the latter per se, but D is meant to be an OO language, is it not? Further, the C-style global methods and so on (module level) do cause notable problems with namespace collisions.

Something to consider ...

This is tricky, since D boasts it's multi-paradigm, having a standard library in OO would kind of hinder those that want to use it as procedural. Maybe the base library should be procedural, and an OO written atop it ? I'm not that crazy about that though. <shrugs>

While I remember, I think this library should be OO. Phobos is pretty loose about this, with much of it implemented more like a traditional C library. I'm not knocking the latter per se, but D is meant to be an OO language, is it not? Further, the C-style global methods and so on (module level) do cause notable problems with namespace collisions.

Something to consider ...

I'm not so sure about this.

Parts of the library that are object oriented in the conceptual sense should use classes. D has builtin syntax to support objects directly, and there's no reason not to take advantage of the fact.

When objects don't fit, objects shouldn't be used. This isn't Java; we aren't forced to shoehorn things into a paradigm that doesn't fit.

Maybe my memory has blurred over some details, but if I recall, the only issues with module-level functions arise when they conflict with methods defined in other scopes. (like std.string.toString) In the absense of function overloading, everything is pretty straightforward._________________"Complacency is a far more dangerous attitude than outrage." - Naomi Littlebear

While I remember, I think this library should be OO. Phobos is pretty loose about this, with much of it implemented more like a traditional C library. I'm not knocking the latter per se, but D is meant to be an OO language, is it not? Further, the C-style global methods and so on (module level) do cause notable problems with namespace collisions.

Something to consider ...

I'm not so sure about this.

Parts of the library that are object oriented in the conceptual sense should use classes. D has builtin syntax to support objects directly, and there's no reason not to take advantage of the fact.

When objects don't fit, objects shouldn't be used. This isn't Java; we aren't forced to shoehorn things into a paradigm that doesn't fit.

Maybe my memory has blurred over some details, but if I recall, the only issues with module-level functions arise when they conflict with methods defined in other scopes. (like std.string.toString) In the absense of function overloading, everything is pretty straightforward.

Andy; Charlie; guess I should have qualified that far better ... I did actually mean at the conceptual level, but at the same time, I do feel Phobos is too loose about it. The latter issues over namespace 'pollution' might be resolved by wrapping those module-level 'things' in a named struct, so they'd have far less change of bumping into names from other libraries and user-code. i.e. System.println() style. Perhaps that would resolve my procedural vs OO conflict Basically, I'm agreeing with you, Andy.

OTOH, I feel it would be a mistake to deliberately go for a procedural approach. Such things are best left to specialist libraries, rather than the standard D one(s) ~ IMO

I don't think that we must limit too much what can and can't be on the standart library at this early stage. I like Python and Java standart library because the give a lot of (standart!) power to their users (AKA "batteries included") compared with the (raquitic) standart C++ library. Let's people put their modules in and we can later decide if something needs to be on another "support" library.

I also doesn't want Phoenix to be limited to a pure OO aproach, as somebody has said this is not Java and we should be using objects where objects made sense, but no more. I have two modules almost ready (they only lacks documentation) for inclusion into Deimos (or Phoenix), the both are for parsing command line arguments; one (optionparser.d) uses an OO approach and the other one (getopt.d) uses a posix style approach so it's up to the user to decide what they need to use.

About the name resolution problems, the named struct solution will work but for some reason I'm not very happy with that, maybe we should ask big W to add namespaces or a keyword to enforce a module to be in his own namespace (so you have to always prepend the module name to his symbols when using it)?

I'm very happy that this project seems to be starting and I will start coding a lot more D now that I know it will not fade away if I put it in Deimos; let's get this started (quickly please! we can improve the process later) and I'm sure D lovers will be making lot's of contributions in no time.

Personaly, I think that "namespace pollution" can be avoided by using more static function interfaces so that the bits they represent are safely tucked away. This would look a lot like a namespace declaration in C++.

I think that's a discussion more for the coding style group, as it has very little to do with functionality and more to do with how we're presenting the code.

Ideally, I think that all the various bits should be as interchangable and optional as possible. This includes the GC which may be in its own lib and hence optional (?). This may help accomodate the systems-programming sub-goal of D, as its nide to be able to pair down the platform to only what you need. To this end, the binary distribution can take on many forms, from many aggregate .lib and .dll files to one monster binary.

Expanding on Kris' idea here's what I envision the layout of Phoenix to be like:

We may want to stay away from anything that is too specific to any one problem domain, at least for now. IMO, Http servers, and the like are probably best left to external projects or at the least as "extensions" as Kris mentioned.

We may also consider what tools and bits that should accompany a binary distribution. Perhaps some standard dll and application stubs along with example makefiles would ease app development. Also, I'm assuming that portability between Win32 and linux is a given... when/how/if are we going to tackle other platforms like BSD and OS X?_________________-- !Eric.t.Anderton at gmail