View previous topic :: View next topic |
Author |
Message |
sean
Joined: 24 Jun 2004 Posts: 609 Location: Bay Area, CA
|
Posted: Fri Aug 27, 2004 10:21 am Post subject: |
|
|
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 |
|
|
juanjo
Joined: 26 Aug 2004 Posts: 7
|
Posted: Fri Aug 27, 2004 12:00 pm Post subject: Core/non-core split? (all standart) |
|
|
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 |
|
|
sean
Joined: 24 Jun 2004 Posts: 609 Location: Bay Area, CA
|
Posted: Fri Aug 27, 2004 12:20 pm Post subject: |
|
|
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 |
|
|
qbert
Joined: 30 Mar 2004 Posts: 209 Location: Dallas, Texas
|
Posted: Fri Aug 27, 2004 12:54 pm Post subject: |
|
|
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 |
|
|
pragma
Joined: 28 May 2004 Posts: 607 Location: Washington, DC
|
Posted: Fri Aug 27, 2004 1:54 pm Post subject: |
|
|
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.
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 |
|
|
jcc7
Joined: 22 Feb 2004 Posts: 657 Location: Muskogee, OK, USA
|
Posted: Fri Aug 27, 2004 1:57 pm Post subject: |
|
|
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 |
|
|
andy
Joined: 15 Mar 2004 Posts: 71
|
Posted: Fri Aug 27, 2004 2:12 pm Post subject: |
|
|
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 |
|
|
teqdruid
Joined: 11 May 2004 Posts: 390 Location: UMD
|
Posted: Fri Aug 27, 2004 2:21 pm Post subject: Two things |
|
|
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 |
|
|
qbert
Joined: 30 Mar 2004 Posts: 209 Location: Dallas, Texas
|
Posted: Fri Aug 27, 2004 2:30 pm Post subject: |
|
|
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 |
|
|
juanjo
Joined: 26 Aug 2004 Posts: 7
|
Posted: Fri Aug 27, 2004 4:21 pm Post subject: We all seem to agree :) |
|
|
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 |
|
|
sean
Joined: 24 Jun 2004 Posts: 609 Location: Bay Area, CA
|
Posted: Fri Aug 27, 2004 4:43 pm Post subject: |
|
|
andy wrote: | I would dump phoenix.core in favour of the main phoenix package |
Agreed. |
|
Back to top |
|
|
pragma
Joined: 28 May 2004 Posts: 607 Location: Washington, DC
|
Posted: Fri Aug 27, 2004 5:27 pm Post subject: Re: We all seem to agree :) |
|
|
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. |
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
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).
|
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.
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 |
|
|
jcc7
Joined: 22 Feb 2004 Posts: 657 Location: Muskogee, OK, USA
|
Posted: Fri Aug 27, 2004 5:53 pm Post subject: Re: We all seem to agree :) |
|
|
pragma wrote: | 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. | 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 |
|
|
sean
Joined: 24 Jun 2004 Posts: 609 Location: Bay Area, CA
|
Posted: Fri Aug 27, 2004 5:55 pm Post subject: Re: We all seem to agree :) |
|
|
pragma wrote: |
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: |
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: |
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 |
|
|
juanjo
Joined: 26 Aug 2004 Posts: 7
|
Posted: Fri Aug 27, 2004 6:21 pm Post subject: I vote for that list! |
|
|
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 |
|
|
|
|
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
|