View previous topic :: View next topic |
Author |
Message |
qbert
Joined: 30 Mar 2004 Posts: 209 Location: Dallas, Texas
|
Posted: Mon Sep 13, 2004 1:29 pm Post subject: Beginnings |
|
|
Ok!
So we got a style guide, we have our 'rudder', should we talk about how we want to organize ares ? And then start discussing the existing problems with phobos ?
The ogranizing will need to be set by the board, ill offer my 2 cents.
Since D is multi-paradigm ( procedural,OO,generic ) , i think we should layer ares so that the purists can use the language without delving into a paradigm they are not comfotable with.
Im voting the base ares library should be free functions ( static methods of class or struct is cool w/ me if it reduces import conflicts ), with an OO lib built atop, then DTL ( or some template library ).
I'm not too fond of the hybrid beast that phobos is now, and while i normally use OO, i dont think we should push it on everyone.
Thoughts ?
Charlie
OT:
I think we should add a toString(char [] ) to std.string also, i recently came across this when applying toString to some template code, and since std.string only has toString(char*), i found it was automatically converting ( dangerous! ) , and causing alot of bugs. |
|
Back to top |
|
|
regan
Joined: 21 Jun 2004 Posts: 23
|
Posted: Mon Sep 13, 2004 3:20 pm Post subject: Re: Beginnings |
|
|
qbert wrote: | Ok!
So we got a style guide, we have our 'rudder', should we talk about how we want to organize ares ? And then start discussing the existing problems with phobos ?
The ogranizing will need to be set by the board, ill offer my 2 cents.
Since D is multi-paradigm ( procedural,OO,generic ) , i think we should layer ares so that the purists can use the language without delving into a paradigm they are not comfotable with.
|
I totally agree with the principle of this statement.
qbert wrote: |
Im voting the base ares library should be free functions ( static methods of class or struct is cool w/ me if it reduces import conflicts ), with an OO lib built atop, then DTL ( or some template library ).
|
I worry that this decision might cause the OO lib to be in-efficient, not simply because it is in turn calling free functions (those should be optimised) but because the free function way might necessarily be less efficient due to it's nature.
For example, I work with C on a daily basis, I write my C in an OO style eg..
typedef struct foo {
..
} Foo;
Foo *foo_init(..);
void foo_free(Foo **f);
.. foo_method(Foo *f, ..);
..etc..
if I were to wrap that in a class I would go..
class CFoo {
this() {
f = foo_init(..);
}
~this() {
foo_free(&f);
}
.. method(..) {
return foo_method(f,..);
}
private:
Foo *f;
}
now, the compiler might not be able to optimise that in the same sort of way as a pure OO solution.
or perhaps I am being paranoid?
qbert wrote: |
I'm not too fond of the hybrid beast that phobos is now, and while i normally use OO, i dont think we should push it on everyone.
|
I agree.
qbert wrote: |
OT:
I think we should add a toString(char [] ) to std.string also, i recently came across this when applying toString to some template code, and since std.string only has toString(char*), i found it was automatically converting ( dangerous! ) , and causing alot of bugs. |
wow, I didn't even realise that was the case.. I'm curious how it caused bugs tho, can you humour me and post an example?
Regan |
|
Back to top |
|
|
pragma
Joined: 28 May 2004 Posts: 607 Location: Washington, DC
|
Posted: Mon Sep 13, 2004 3:26 pm Post subject: Goals. |
|
|
So far we have a wealth of discussion here, in the DNG and a few places on the wiki that outline the desires and wishes for an improved phobos namespace. Much more lip service has been given to the desired feature improvements as well.
Now its time to roll everything up into a strong set of goals, suitable for further discussion and assignment.
I think the first step is to actually write up (yea, no coding, but it needs to be done) the coding standards and implementation guidelines so we have something to follow. As changes are proposed, they get added so we can all adjust accordingly. This should be placed on the wiki, and later moved to a more permanent home on an ares website (possibly here on dsource?)
Barring that one preliminary (and unfun) task, the rest is design and coding: our favorite!
As I see it, there are several functional areas that need to be addressed:
- Core types and classes (e.g. String, Exception and others that get used everywhere else)
- DLL (library management, GC hooking, type libraries and more)
- I/O (including sockets, buffering, streams, etc)
- System (process, thread and GC)
- Containers
- Unicode
- [something else?]
The appropriate namespaces should fall out of these categories quite easily.
Also up for debate: should string stand on its own or be made dependent upon a container library for flexibility's sake?
In response to qbert: its a cool idea, but I don't think the entire library needs to be "triple-headed" like you suggest (OO, FF and Generic). I would like to see each library coded with the highest degree of flexibility in mind rather than shoehorn a given type of library into three separate implementation paradigms. However, there are cases where we can double things up to make certain coding tasks easier like FF strings that mimic objects.
Continuing on the previous idea, I think the containers portion of Ares could benefit from using template function sets that mimic the proposed solution for strings. That way, one could freely interoperate with D's arrays and the provided template mechanisms.
Thinking further down the road: After we're done deciding what areas need to be covered, we can then ask our host (Brad) to start the SVN repository so we have somewhere to host our efforts.
The implementation should follow soon thereafter, and we can sort out bugs and design issues as we go. We can always get more organized with tracking tools if the volume of messageboard traffic and emails becomes too much.
So to recap: preliminary (simple) design doc first, flesh out target library areas second, setup SVN repository third, and task implementation in certain sections fourth. Each task adds to the design doc as we go. _________________ -- !Eric.t.Anderton at gmail |
|
Back to top |
|
|
qbert
Joined: 30 Mar 2004 Posts: 209 Location: Dallas, Texas
|
Posted: Mon Sep 13, 2004 3:44 pm Post subject: |
|
|
Quote: | For example, I work with C on a daily basis, I write my C in an OO style eg.. |
Hmm good call , thats what i consider good C style too. Its one of those awful tradeoff decisions that the board has to make .
Quote: | wow, I didn't even realise that was the case.. I'm curious how it caused bugs tho, can you humour me and post an example? |
Hmm its been a while, it was for dig-dug, can't find it.
Heres a 'not-likely-to-happen' problem though.
Code: |
module foo;
import std.stream;
import std.string;
void main ()
{
char [] x = "Like ma bell \0 got the ill communication \0";
stdout.writeLine(toString(x));
return;
}
|
|
|
Back to top |
|
|
teqdruid
Joined: 11 May 2004 Posts: 390 Location: UMD
|
Posted: Mon Sep 13, 2004 6:44 pm Post subject: |
|
|
Quote: | I/O (including sockets, buffering, streams, etc) |
I would vote for using Mango's I/O stuff. It relies on some stuff in phobos, but not to much methinks. Perhaps someone should set up a vote for this soon.
Quote: | - Core types and classes (e.g. String, Exception and others that get used everywhere else) |
-printf ? or writef? |
|
Back to top |
|
|
pragma
Joined: 28 May 2004 Posts: 607 Location: Washington, DC
|
Posted: Tue Sep 14, 2004 7:46 am Post subject: |
|
|
Quote: | -printf ? or writef? |
Personally, I think that format/writef belongs in the IO tree and printf (and friends) should probably stay in a more legacy-oriented tree; something like "legacy.c" or "legacy.std" or "std.c". _________________ -- !Eric.t.Anderton at gmail |
|
Back to top |
|
|
teqdruid
Joined: 11 May 2004 Posts: 390 Location: UMD
|
Posted: Tue Sep 14, 2004 1:11 pm Post subject: |
|
|
Quote: | printf (and friends) should probably stay in a more legacy-oriented tree; something like "legacy.c" or "legacy.std" or "std.c". |
Isn't having legacy and c in the same module name kinda superfluous? How about just the module name "obsolete"?
Although it is kinda useful to have printf in object like it is now... makes debugging easier.
Quote: | Personally, I think that format/writef belongs in the IO tree |
I agree. Actually, I think Mango already has this. |
|
Back to top |
|
|
sean
Joined: 24 Jun 2004 Posts: 609 Location: Bay Area, CA
|
Posted: Thu Sep 16, 2004 10:35 am Post subject: |
|
|
I say leave all the standard C headers in std.c and define the rest elsewhere. It would be nice to provide free functions when possible, but I don't want that to be a development requirement. I would like a small set of io functions however--at least writef/readf. This would allow folks to roll their own i/o classes without needing to follow our design if they don't want to. |
|
Back to top |
|
|
qbert
Joined: 30 Mar 2004 Posts: 209 Location: Dallas, Texas
|
Posted: Tue Sep 21, 2004 10:27 am Post subject: Re: Goals. |
|
|
pragma wrote: | So to recap: preliminary (simple) design doc first, flesh out target library areas second, setup SVN repository third, and task implementation in certain sections fourth. Each task adds to the design doc as we go. |
Ok so we have Lar's design doc, should we start fleshing out ares?
pragma wrote: | Also up for debate: should string stand on its own or be made dependent upon a container library for flexibility's sake? |
Hmm. I vote standalone, because we can already have free functions that act like methods on arrays, and I think D's array stuff make it great.
What benefit would come from making a container for it ?
Quote: | - Core types and classes (e.g. String, Exception and others that get used everywhere else)
- DLL (library management, GC hooking, type libraries and more)
- I/O (including sockets, buffering, streams, etc)
- System (process, thread and GC)
- Containers
- Unicode |
These look good, should we layout the module/package heiarchy ? With a description of the modules functionailty listed under it ? |
|
Back to top |
|
|
pragma
Joined: 28 May 2004 Posts: 607 Location: Washington, DC
|
Posted: Tue Sep 21, 2004 1:56 pm Post subject: Namespace |
|
|
To continue the thread, I thought it might be helpful to jump forward to a more complete namespace layout. If this passes muster here, we can then divy up who does what.
Current Phobos Layout (internal and typeinfo trees omitted for brevity)
Code: |
crc32
gcstats
object
unittest
etc.loader
etc.c.zlib
std.array
std.asserterror
std.base64
std.boxutil
std.compiler
std.conv
std.ctype
std.date
std.dateparse
std.file
std.format
std.gc
std.intrinsic
std.loader
std.math
std.math2
std.md5
std.mmfile
std.moduleinit
std.outbuffer
std.outofmemory
std.path
std.perf
std.process
std.random
std.recls
std.regexp
std.socket
std.socketstream
std.stdarg
std.stdint
std.stdio
std.stream
std.string
std.switcherr
std.syserror
std.system
std.thread
std.unittest
std.uri
std.utf
std.zip
std.zlib
std.c.math
std.c.process
std.c.stdarg
std.c.stdio
std.c.stdlib
std.c.time
std.c.linux.linux
std.c.linux.linuxextern
std.c.windows.com
std.c.windows.windows
std.windows.iunknown
std.windows.registry
|
Ares Namespace (proposed refactoring of phobos)
Code: |
internal.gcstats - from phobos root
internal.unittest - from phobos root
internal.array - from std.array
internal.asserterror - from std.asserterror
internal.outofmemory - from std.outofmemory
internal.moduleinit - from std.moduleinit
internal.typeinfo.* - from all of std.typeinfo
internal.* - from all of internal
internal.gc.* - from all of internal.gc
std.util.crc32 - from crc32
std.util.recls - from std.recls
std.util.random - from std.random
std.util.perform - from std.perf
std.util.regexp - from std.regexp
std.util.md5 - from std.md5
std.util.zip - from std.zip
std.util.zlib - from std.zlib (also replaces etc.c.zlib)
std.library.library - replaces std.loader (from DSP)
std.library.stub - from DSP
std.library.libraryCache - from DSP
std.library.all - (all of above)
std.system.system - from std.system
std.system.gc - from std.gc
std.system.process - from std.process
std.system.thread - from std.thread
std.system.concurrent - possibly contributed from Concurrent at dsource
std.system.error - replaces std.syserror
std.system.path - replaces std.path
std.system.all - (all of above)
std.io.* - replaces file, format, mmfile, stdio, outbuffer, socket, socketstream, uri and stream (from Mango)
std.io.all
std.type.exception
std.type.base64 - from std.base64
std.type.convert - from std.conv (needs heavy refactoring for additional types)
std.type.ctype - from std.ctype
std.type.datetime - from std.date and std.dateparse
std.type.int - from std.stdint
std.type.utf - from std.utf
std.type.string - from std.string (needs heavy refactoring/rewriting)
std.type.all
std.math.math - from std.math and std.math2
std.math.all
std.object
std.compiler - needs versioning for DigitalMars, GCD, DCC and possibly D.NET
std.intrinsic
std.stdarg
std.switcherr
std.c.math
std.c.process
std.c.stdarg
std.c.stdio
std.c.stdlib
std.c.time
std.c.linux.linux
std.c.linux.linuxextern
std.c.windows.com
std.c.windows.win32
std.windows.iunknown
std.windows.registry
|
A few notes:
This is a proposal, and I welcome (and want) everyone here to shoot it full of holes, tear it down and make it stronger with good feedback.
I feel that the internal tree should be something that could easily be compiled into its own library. That is, it should support the compiler's understanding of D code and remain independent of Ares/Phobos. Also this tree could be retargeted into other minimal libraries suitable for embedded programming, as they would be nice and small.
Also, this is only complete from the perspective of refactoring the current library. There is much more that can be added on top of this. _________________ -- !Eric.t.Anderton at gmail |
|
Back to top |
|
|
larsivi Site Admin
Joined: 27 Mar 2004 Posts: 453 Location: Trondheim, Norway
|
Posted: Tue Sep 21, 2004 2:17 pm Post subject: |
|
|
I'm to tired to think clearly, but I don't think std.ctype and std.utf is anywhere close to what is needed for internationalization. I don't know enough about what's good enough, except that the current stuff isn't good enough. |
|
Back to top |
|
|
pragma
Joined: 28 May 2004 Posts: 607 Location: Washington, DC
|
Posted: Tue Sep 21, 2004 2:25 pm Post subject: |
|
|
larsivi wrote: | I'm to tired to think clearly, but I don't think std.ctype and std.utf is anywhere close to what is needed for internationalization. I don't know enough about what's good enough, except that the current stuff isn't good enough. |
I agree that many of the phobos libs are substandard... that is what this project is for anyway.
When you get a chance, could you post a list of files that you think should be scrubbed from the list? Also, what addtions can you forsee?
Also, I found this on the wiki
http://www.prowiki.org/wiki4d/wiki.cgi?StandardLibrary/Layout
Following this, the linux and windows parts probably shouldn't go under std.c at all since they are not really legacy interfaces. However, I don't agree with the wiki as win32 and win64 should be distinct enough to put them in different files. As it stands, MSVC is organized the same way.
Code: |
std.os.linux
std.os.linuxextern
std.os.windows.win32
std.os.windows.win64
std.os.windows.com
std.os.windows.iunknown
|
Also I think Helmut or someone else on the wiki proposed that the win32 section of phobos be broken down into multiple files... but I haven't a clue where it is. _________________ -- !Eric.t.Anderton at gmail |
|
Back to top |
|
|
jcc7
Joined: 22 Feb 2004 Posts: 657 Location: Muskogee, OK, USA
|
Posted: Tue Sep 21, 2004 4:00 pm Post subject: Win32 Headers |
|
|
pragma wrote: | Also I think Helmut or someone else on the wiki proposed that the win32 section of phobos be broken down into multiple files... but I haven't a clue where it is. |
I think you're thinking of a couple of my replies to Helmut:
digitalmars.D:10718
digitalmars.D:10756
jcc7 wrote: | I agree with this, but I think there'd be too much code for one file (windows.d is already huge as it is). It should be split into multiple modules:
std.c.windows.commdlg
std.c.windows.ole2
std.c.windows.oleauto
std.c.windows.oleextra
std.c.windows.winbase
std.c.windows.windef
std.c.windows.wingdi
std.c.windows.winnt
std.c.windows.winuser
std.c.windows.wtypes |
My basis thesis is: std.c.windows.windows is already a fairly large file (78 kb) and my guess is that it doesn't even contain 50? of the definitions that it should have. I'm basing my guess by looking at the sizes of winbase.d (114 kb), winuser (134 kb), wingdi (123 kb), winnt (134 kb), etc, in the Core32 project. There might be some wasted space in Core32, but not that much. If we keep it all in one file, it's going to get huge. Microsoft doesn't keep them all in one file, why should we? |
|
Back to top |
|
|
jcc7
Joined: 22 Feb 2004 Posts: 657 Location: Muskogee, OK, USA
|
Posted: Tue Sep 21, 2004 4:04 pm Post subject: Re: Namespace |
|
|
pragma wrote: | Ares Namespace (proposed refactoring of phobos)
| The only inconsistency that I spotted is that shouldn't std.switcherr become internal.switcherr?
Looks good! |
|
Back to top |
|
|
pragma
Joined: 28 May 2004 Posts: 607 Location: Washington, DC
|
Posted: Tue Sep 21, 2004 5:58 pm Post subject: Re: Namespace |
|
|
jcc7 wrote: | pragma wrote: | Ares Namespace (proposed refactoring of phobos)
| The only inconsistency that I spotted is that shouldn't std.switcherr become internal.switcherr?
Looks good! |
Thanks. So which part would you like to work on?
Actually, switcherr and a few others (outofmemory for example) define both an error class as well as a handler that is linked against by the compiler (presumably).
Code: |
class SwitchError : Object;
extern (C) static void _d_switch_error(char[] filename, uint line);
|
This makes things trickier than just moving the whole file to one source tree. In this case _d_switch_error uses the SwitchError class directly. So you're right, we need to move this to internal, but we should also throw the class definitions into std.exception for now. _________________ -- !Eric.t.Anderton at gmail |
|
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
|