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 Previous  1, 2, 3, 4  Next
 
Post new topic   Reply to topic     Forum Index -> Ares
View previous topic :: View next topic  
Author Message
sean



Joined: 24 Jun 2004
Posts: 609
Location: Bay Area, CA

PostPosted: Fri Aug 27, 2004 10:21 am    Post subject: Reply with quote

I agree with kris that we should keep the core library small and provide additional functionality in supplementary libraries. Things like http (and other protocols), encryption, compression, and a full-blown Unicode lib likely belong here. Some of the things I would like to see in the core lib are:

- containers
- algorithms
- basic filesystem functionality
- i/o support (both binary and at least limited formatted support)
- threading
- at least some basic (Unicode-aware) string handling routines, including transcoding routines
- possibly sockets (a basic design that is easily extensible, since I'd want it to be able to scale well to multiplexex approaches... actually, the entire i/o library should scale this way since files and sockets are practically indistinguishable in many cases)

I think DTL takes care of the containers, and algorithms probably belong there as well. And it's important to keep portability in mind. Places where this will be an issue are with i/o, the filesystem, and threading.
Back to top
View user's profile Send private message
juanjo



Joined: 26 Aug 2004
Posts: 7

PostPosted: Fri Aug 27, 2004 12:00 pm    Post subject: Core/non-core split? (all standart) Reply with quote

Again, I don't like the standart lib to be limited to the core funcionality. I just don't see the advantage (if you do, please explain it to me). The power of standart libraries is one of the biggest selling points of languages (ever looked at C#, Python or Java?). A solution would be to have a "core" part of the library and a "non-core" or extended part, both being considered "standart". The core part would all reside on a single dll/so and the extensions would have each each is own dll/so, so users not wanting to link againt things they're not using have the chance to do so.
Back to top
View user's profile Send private message MSN Messenger
sean



Joined: 24 Jun 2004
Posts: 609
Location: Bay Area, CA

PostPosted: Fri Aug 27, 2004 12:20 pm    Post subject: Reply with quote

Right. I think that's what kris and I were suggesting. The "core" library would contain essential functionality and then a series of supplemental libraries would contain other stuff. But the design and interaction across all libraries would be consistent and have the feel of a single unified library. This would provide users maximum flexibility and reduce the chance of code bloat from unused code.
Back to top
View user's profile Send private message
qbert



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

PostPosted: Fri Aug 27, 2004 12:54 pm    Post subject: Reply with quote

Ok, so how is this going to layout ? Whats the organzitional structure for 'core lib', and 'extended libs' ?

pheonix.core.*
pheonix.ext.*

?

( On a side note how about some design patterns code for ext. ( or whatever its name is going to be ) ).

Charlie
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 1:54 pm    Post subject: Reply with quote

qbert wrote:
Ok, so how is this going to layout ? Whats the organzitional structure for 'core lib', and 'extended libs' ?

pheonix.core.*
pheonix.ext.*


That's probably about as good as it gets. I can easily see the following happen:

pheonix.core.std;
pheonix.core.io;
pheonix.core.system;
pheonix.core.thread;
pheonix.core.string;
pheonix.core.containers;

For grins we can provide pheonix.core.all; to import everything.

pheonix.ext.unicode;
pheonix.ext.http;
.. and so on.

Arrow One suggestion: with respect to an IO lib, I'd really like to see a core (unified?) I/O library that can handle files, console and sockets all by itself, with ancillary (core.fileio, core.socketio, etc) librarys providing more expressive support. I think that'll also help with the library's portability.

qbert wrote:
( On a side note how about some design patterns code for ext. ( or whatever its name is going to be ) ).


I adore my Design Patterns book, and have wanted a DP interface lib for some time now. I haven't ever coded against such a thing, so I haven't a clue what value it will bring. ::shrug::
_________________
-- !Eric.t.Anderton at gmail
Back to top
View user's profile Send private message Yahoo Messenger
jcc7



Joined: 22 Feb 2004
Posts: 657
Location: Muskogee, OK, USA

PostPosted: Fri Aug 27, 2004 1:57 pm    Post subject: Reply with quote

qbert wrote:
Ok, so how is this going to layout ? Whats the organzitional structure for 'core lib', and 'extended libs' ?

pheonix.core.*
pheonix.ext.*
I'm wondering if the separation between the core and the extensions may be more of a concept than something that concrete.

We may want to do something like this:

Core (phoenix.lib):
phoenix.arg (compare to std.stdarg)
phoenix.error.asserterr
phoenix.error.switcherr
phoenix.gc
phoenix.string

Extensions:
phoenix.ext.httpserver (httpserver.lib)
phoenix.ext.unicode (unicode.lib)

Of course, we'll need to iron out what's core and what's an extension, too. I think the small things and things required by the compiler would automatically be in the core. (Also, if we could turn the gc into a .dll, then we could take it out of the core.)
Back to top
View user's profile Send private message AIM Address
andy



Joined: 15 Mar 2004
Posts: 71

PostPosted: Fri Aug 27, 2004 2:12 pm    Post subject: Reply with quote

I would dump phoenix.core in favour of the main phoenix package. phoenix.ext can be extra. So, for instance, we would have
Code:
import phoenix.io;
import phoenix.string;
import phoenix.ext.dwt;


Large, deep package heirarchies have a way of becoming very intimidating and hard to navigate. A flatter structure would be more approachable. (the Python standard library is a good example of this)

(of course, this makes the problem of namespace clutter a fair bit bigger...)
_________________
"Complacency is a far more dangerous attitude than outrage." - Naomi Littlebear
Back to top
View user's profile Send private message
teqdruid



Joined: 11 May 2004
Posts: 390
Location: UMD

PostPosted: Fri Aug 27, 2004 2:21 pm    Post subject: Two things Reply with quote

Here's two points I haven't seen anyone mention yet:
-Mango IO... Mango's got some neat IO stuff... why not use that? Plus, it's done, and it works.

-String. I'm so sick of these std.string functions. Let's do two things: 1) Get AJ's ICU port and add whatever methods are necessary make it a viable replacement for std.string. 2) Make a String class that will wrap the functions. If it uses ICU, it shouldn't be too hard to make it completely Unicode compliant. It would also be nice if there were some way to make it implicitly convertable to/from (d/w)char arrays, but I don't think that's currently possible with the compiler.
Back to top
View user's profile Send private message Send e-mail AIM Address
qbert



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

PostPosted: Fri Aug 27, 2004 2:30 pm    Post subject: Reply with quote

Quote:
I would dump phoenix.core in favour of the main phoenix package. phoenix.ext can be extra. So, for instance, we would have


Quote:
I'm wondering if the separation between the core and the extensions may be more of a concept than something that concrete.



Sounds good to me.
Back to top
View user's profile Send private message MSN Messenger
juanjo



Joined: 26 Aug 2004
Posts: 7

PostPosted: Fri Aug 27, 2004 4:21 pm    Post subject: We all seem to agree :) Reply with quote

This is going very well, I like the phoenix.core or phoenix.* for the core and phoenix.ext.* for standart extensions. Extending this idea phoenix could also have phoenix.wrappers (phoenix.wrap.windows, phoenix.wrap.posix, etc) for D modules that basically wrap existing C libraries.

We should also start populating deimos with candidates to phoenix and at least we need a minimal framework on which other modules could build on, like:

* IO Streams (and at least file-streams and socket-streams), Mango?

* String class (doesn't matter too much if it isn't Unicode from the begining because most modules, I guess, won't be using their Unicode facilities and that's also we can add later once AJ completes his wonderfull ICU port). The Dool String class could be a nice start.

* Non object oriented string methods (like std.string, but probably better) for the people that wants/need to program usaing char[]'s instead of String objects including, of course, quick & nice format & unformat, write/writeln and the such (we can just start with phobos std.string).

* Some basic system information (but more than system.d).

* Date and time functions.

* Threads and process module.

* path.d/filesystem.d for filesystem info and the such (get file type, permissions, path transformations, check for existance, etc.)

* math.d

* compiler.d, gc.d

* dtl, at least a basic version of it that other modules can start to use for their data structures (since we control everything the modules can be keept in sync with dtl improvements easily).

I think that once we have these modules in place (every one of them using the others) in the core there can be an explosion of phoenix.ext modules (for example having String, Streams and Socket I will be able to write modules for handling the POP3 and IMAP4 mail protocols.)

Also, not everything must be set on stone (API designs, coding conventions) before we adding things to Deimos (or even an early Phoenix); we can start developing now and fix the modules later when we have settled on some standarts.
Back to top
View user's profile Send private message MSN Messenger
sean



Joined: 24 Jun 2004
Posts: 609
Location: Bay Area, CA

PostPosted: Fri Aug 27, 2004 4:43 pm    Post subject: Reply with quote

andy wrote:
I would dump phoenix.core in favour of the main phoenix package

Agreed.
Back to top
View user's profile Send private message
pragma



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

PostPosted: Fri Aug 27, 2004 5:27 pm    Post subject: Re: We all seem to agree :) Reply with quote

juanjo wrote:
This is going very well, I like the phoenix.core or phoenix.* for the core and phoenix.ext.* for standart extensions. Extending this idea phoenix could also have phoenix.wrappers (phoenix.wrap.windows, phoenix.wrap.posix, etc) for D modules that basically wrap existing C libraries.


Idea Actually, since these wrappers are really platform-based technologies, perhaps "platform" might be more appropriate.

phoenix.platform.win32
phoenix.platform.win64
phoenix.platform.posix
phoenix.platform.linux
phoenix.platform.bsd
phoenix.platform.osx

Arrow It feels like we're all beginning to home in on a common namespace. Here's a compilation of everyone's suggestions (hope I didn't leave anything out):

phoenix.io (all io, file, socket, console, buffers)
phoenix.string (char[] only, assuming that ICU is used for ext.unicode)
phoenix.system (more complete than std.system)
phoenix.datetime ("date" or "time" if anyone prefers)
phoenix.thread (or "threading" - process and threading)
phoenix.filesystem (if we use mango, this is already in "io".. does it have to be separate?)
phoenix.math
phoenix.compiler
phoenix.gc
phoenix.dtl (or containers if DTL isn't ready or doesn't belong here)

I'd personally like to see these additions if everyone is okay with the above:

phoenix.sync (locked and lockless synchronization - may be included in .thread)
phoenix.ext.unicode
phoenix.ext.big
phoenix.ext.crypto
...and so on.

juanjo wrote:
* Non object oriented string methods (like std.string, but probably better) for the people that wants/need to program usaing char[]'s instead of String objects including, of course, quick & nice format & unformat, write/writeln and the such (we can just start with phobos std.string).


Question As much as I'm used to working with entire libraries of free functions, they do tend to create problems if identifiers happen to overlap between unrelated libraries. To side-step this "namespace pollution" would you (or many others?) be adverse to using static methods of a class as opposed to free functions?

IMO, all the namespaces should tread lightly and leave as small a footprint on its containing namespace as possible, due to the flat-alias nature of "import".

My primary concern is that "phoenix.string" and and "phoenix.ext.unicode" will butt-heads immediately once you start working with both, if they both use free functions (not to mention there are countless ways that we tie the end-devleoper's hands by having crowded namespaces). IMO, having to use "String.concat()" and "UString.concat()" is a small price to pay for a solid, caveat-free library. Smile


juanjo wrote:

Also, not everything must be set on stone (API designs, coding conventions) before we adding things to Deimos (or even an early Phoenix); we can start developing now and fix the modules later when we have settled on some standarts.


I agree. But we do need to be sure that most everyone is on the same page before we just jump into subversion and upload code like crazy.
_________________
-- !Eric.t.Anderton at gmail
Back to top
View user's profile Send private message Yahoo Messenger
jcc7



Joined: 22 Feb 2004
Posts: 657
Location: Muskogee, OK, USA

PostPosted: Fri Aug 27, 2004 5:53 pm    Post subject: Re: We all seem to agree :) Reply with quote

pragma wrote:
Question As much as I'm used to working with entire libraries of free functions, they do tend to create problems if identifiers happen to overlap between unrelated libraries. To side-step this "namespace pollution" would you (or many others?) be adverse to using static methods of a class as opposed to free functions?

IMO, all the namespaces should tread lightly and leave as small a footprint on its containing namespace as possible, due to the flat-alias nature of "import".

My primary concern is that "phoenix.string" and and "phoenix.ext.unicode" will butt-heads immediately once you start working with both, if they both use free functions (not to mention there are countless ways that we tie the end-devleoper's hands by having crowded namespaces). IMO, having to use "String.concat()" and "UString.concat()" is a small price to pay for a solid, caveat-free library. Smile
Maybe we could have a package called phoenix.oo.* with class wrappers for frequently clashing modules? Then, you could import phoenix.oo.string and import phoenix.oo.etc.unicode and access them with static class methods. But if you're only or mostly using one or the other, you can use them the quick way.

I guess I'd like it to be super-easy to do easy things and not-too-hard to harder things (if that makes any sense).

Another idea is since the string vs. unicode issue will surely be a common challenge, can't we create a "unification" module that uses alias to choose the unicode version when there's a clash and import the non-overlapping portions from each module. Maybe it's a crazy idea, but I think it might work.

Lastly, we can use alias tricks to shorten the names of the modules. Something like this:
Code:
alias phoenix.etc.unicode uniStr;
alias phoenix.string charStr;
I know that doesn't buy much, but it's something.
Back to top
View user's profile Send private message AIM Address
sean



Joined: 24 Jun 2004
Posts: 609
Location: Bay Area, CA

PostPosted: Fri Aug 27, 2004 5:55 pm    Post subject: Re: We all seem to agree :) Reply with quote

pragma wrote:

Idea Actually, since these wrappers are really platform-based technologies, perhaps "platform" might be more appropriate.

phoenix.platform.win32
phoenix.platform.win64
phoenix.platform.posix
phoenix.platform.linux
phoenix.platform.bsd
phoenix.platform.osx

Sounds good, though I hesitate to expect users to explicitly access platform-specific namespaces. Are the platform ones really necessary? Or perhaps they could be for internal use?

pragma wrote:

Arrow It feels like we're all beginning to home in on a common namespace. This following is

phoenix.io (all io, file, socket, console, buffers)
phoenix.string (char[] only, assuming that ICU is used for ext.unicode)
phoenix.system (more complete than std.system)
phoenix.datetime ("date" or "time" if anyone prefers)
phoenix.thread (or "threading" - process and threading)
phoenix.filesystem (if we use mango, this is already in "io".. does it have to be separate?)
phoenix.math
phoenix.compiler
phoenix.gc
phoenix.dtl (or containers if DTL isn't ready or doesn't belong here)

I'd personally like to see these additions if everyone is okay with the above:

phoenix.sync (locked and lockless synchronization - may be included in .thread)
phoenix.ext.unicode
phoenix.ext.big
phoenix.ext.crypto
...and so on.

That list looks pretty good to me. Maybe add phoenix.algorithm, which would likely be a supplementary part of dtl.

pragma wrote:

Question As much as I'm used to working with entire libraries of free functions, they do tend to create problems if identifiers happen to overlap between unrelated libraries. To side-step this "namespace pollution" would you (or many others?) be adverse to using static methods of a class as opposed to free functions?

Not at all. I assume you're suggesting we code stuff as usual, private import those modules and then alias everything in structs?


pragma wrote:

I agree. But we do need to be sure that most everyone is on the same page before we just jump into subversion and upload code like crazy.

Definately. And if we really need to start talking about practicalities now then how about we start with Exceptions/Errors? They're pretty essential to every other project.
Back to top
View user's profile Send private message
juanjo



Joined: 26 Aug 2004
Posts: 7

PostPosted: Fri Aug 27, 2004 6:21 pm    Post subject: I vote for that list! Reply with quote

I also like the compiled namespace module list, let's start talking about exceptions! (I have so toughts about that but they'll have to wait for tomorrow).

I also don't have any problem with using static class methods instead of free functions, but we definitivelly need to push big W to create a new import keyword (namedimport or importnamed or something like that, suggestions for the suggestion? I'll probably post something tomorrow about that on the NG).
Back to top
View user's profile Send private message MSN Messenger
Display posts from previous:   
Post new topic   Reply to topic     Forum Index -> Ares All times are GMT - 6 Hours
Goto page Previous  1, 2, 3, 4  Next
Page 2 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