FAQFAQ   SearchSearch   MemberlistMemberlist   UsergroupsUsergroups   RegisterRegister 
 ProfileProfile   Log in to check your private messagesLog in to check your private messages   Log inLog in 

Open Call for Suggestions: Project Direction and Features
Goto page 1, 2, 3, 4  Next
 
Post new topic   Reply to topic     Forum Index -> Ares
View previous topic :: View next topic  
Author Message
pragma



Joined: 28 May 2004
Posts: 607
Location: Washington, DC

PostPosted: Thu Aug 26, 2004 6:57 pm    Post subject: Open Call for Suggestions: Project Direction and Features Reply with quote

This is an open call for suggestions on where this project should go.

Question The underlying premise is that the D Phobos library is lacking in support for many things, and that we're here to help! What can we (all of us) do to make D a better language?

Exclamation I'd like to ask that everyone who has contributed project related suggestions, that they repost their thoughts here so we can have everything in one place.

We're looking for the following information (not at all a complete list):
- Final project name
- Project scope: what functionality do we wish to cover
- Readily available libraries to include

Suggestions for Coding Standards, being the usual hot topic that it is, should be made in the appropriate topic (not here).

Thank you.
_________________
-- !Eric.t.Anderton at gmail
Back to top
View user's profile Send private message Yahoo Messenger
kris



Joined: 27 Mar 2004
Posts: 1494
Location: South Pacific

PostPosted: Thu Aug 26, 2004 7:56 pm    Post subject: Reply with quote

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

Arrow As far as the name goes, I think Phoenix is rather appropos
Back to top
View user's profile Send private message
pragma



Joined: 28 May 2004
Posts: 607
Location: Washington, DC

PostPosted: Thu Aug 26, 2004 9:12 pm    Post subject: NG Post Reply with quote

Derek Parnell chipped in with a good summary of our status so far on the DNG.

http://www.digitalmars.com/drn-bin/wwwnews?digitalmars.D/9807
_________________
-- !Eric.t.Anderton at gmail
Back to top
View user's profile Send private message Yahoo Messenger
pragma



Joined: 28 May 2004
Posts: 607
Location: Washington, DC

PostPosted: Thu Aug 26, 2004 9:14 pm    Post subject: Reply with quote

Deja Augustine also lended some input over at the DNG.

http://www.digitalmars.com/drn-bin/wwwnews?digitalmars.D/9806

(this is split across both the present open calls to help channel the input a little)


Once the library standard has been codified, then it should be posted to
the NG for comments and criticism. After a period of, say, one week of
discussion, a final set of rules would be drawn up.

Once the rules are in place, the "committee" should post a list of all
of the various library features and "contract" out those tasks to people
such that the list could look something like:

Feature - Author - Date Started - Last Update - ?
...
Regular Expressions - Deja Augustine - 08/26/2004 - 08/26/2004 - 0?
File Streams - ... - ... - ... - ...
...


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.

_________________
-- !Eric.t.Anderton at gmail
Back to top
View user's profile Send private message Yahoo Messenger
pragma



Joined: 28 May 2004
Posts: 607
Location: Washington, DC

PostPosted: Thu Aug 26, 2004 9:20 pm    Post subject: Reply with quote

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


Cool 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
Back to top
View user's profile Send private message Yahoo Messenger
kris



Joined: 27 Mar 2004
Posts: 1494
Location: South Pacific

PostPosted: Thu Aug 26, 2004 10:13 pm    Post subject: Reply with quote

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


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

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

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

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

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

Arrow 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?

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

Arrow 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
Back to top
View user's profile Send private message
andy



Joined: 15 Mar 2004
Posts: 71

PostPosted: Thu Aug 26, 2004 11:12 pm    Post subject: Reply with quote

kris brings up a good point: there should be a rule of thumb for what should not be covered as well.
_________________
"Complacency is a far more dangerous attitude than outrage." - Naomi Littlebear
Back to top
View user's profile Send private message
kris



Joined: 27 Mar 2004
Posts: 1494
Location: South Pacific

PostPosted: Thu Aug 26, 2004 11:29 pm    Post subject: Reply with quote

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 ...
Back to top
View user's profile Send private message
qbert



Joined: 30 Mar 2004
Posts: 209
Location: Dallas, Texas

PostPosted: Thu Aug 26, 2004 11:31 pm    Post subject: Reply with quote

Quote:
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 Wink, in which case you might have to rename it to (D)(P)heonix(G)roup or something... )

Question
Back to top
View user's profile Send private message MSN Messenger
kris



Joined: 27 Mar 2004
Posts: 1494
Location: South Pacific

PostPosted: Thu Aug 26, 2004 11:38 pm    Post subject: Reply with quote

qbert wrote:
Quote:
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 Wink, in which case you might have to rename it to (D)(P)heonix(G)roup or something... )

Question

One might also think of DSLG as the DSource Library Group Cool

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
Back to top
View user's profile Send private message
qbert



Joined: 30 Mar 2004
Posts: 209
Location: Dallas, Texas

PostPosted: Thu Aug 26, 2004 11:40 pm    Post subject: Reply with quote

kris wrote:
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>
Back to top
View user's profile Send private message MSN Messenger
andy



Joined: 15 Mar 2004
Posts: 71

PostPosted: Fri Aug 27, 2004 12:18 am    Post subject: Reply with quote

kris wrote:
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
Back to top
View user's profile Send private message
kris



Joined: 27 Mar 2004
Posts: 1494
Location: South Pacific

PostPosted: Fri Aug 27, 2004 12:43 am    Post subject: Reply with quote

andy wrote:
kris wrote:
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 Confused 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
Back to top
View user's profile Send private message
juanjo



Joined: 26 Aug 2004
Posts: 7

PostPosted: Fri Aug 27, 2004 1:12 am    Post subject: Thoughts Reply with quote

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.
Back to top
View user's profile Send private message MSN Messenger
pragma



Joined: 28 May 2004
Posts: 607
Location: Washington, DC

PostPosted: Fri Aug 27, 2004 8:04 am    Post subject: Reply with quote

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

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

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

- gc (possibly in its own library?)
- std (common bits that are used everywhere, like TypeInfo, etc)
- stream
- stdio (console in/out)
- fileio
- socketio
- system
- thread
- sync (syncronization primitives similar to "concurrent")
- string (maybe belongs in std?)
- unicode (ICU Port)
- big (bigint and others?)

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

Idea I've been kicking around some ideas that may be a good to include:

- application (application object management and event model)
- library (dll management and event model)
- typelibrary (dll-style classfactory)

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
Back to top
View user's profile Send private message Yahoo Messenger
Display posts from previous:   
Post new topic   Reply to topic     Forum Index -> Ares All times are GMT - 6 Hours
Goto page 1, 2, 3, 4  Next
Page 1 of 4

 
Jump to:  
You cannot post new topics in this forum
You cannot reply to topics in this forum
You cannot edit your posts in this forum
You cannot delete your posts in this forum
You cannot vote in polls in this forum


Powered by phpBB © 2001, 2005 phpBB Group