August 16, 2003 Re: Standard D Library | ||||
---|---|---|---|---|
| ||||
Posted in reply to Burton Radons | I want to encourage everyone to help out with the library. My primary focus, as you all have guessed by now, is making the compiler itself the best it can be. Phobos has been a bit neglected as a result. I, of course, will take on the task of the necessary runtime support for the language semantics, such as making sure the exception handling stack unwinder works. But the stuff that makes a library full and great, I'm not too good at. A couple philosophical points on what I think makes a good library: 1) Loose coupling. This is important so that small apps can be created. In Java, it turned out that every class was dependent on every other class, so the smallest app pulled in the entire library. Library modules should be as decoupled as practical. Calling a directory function shouldn't pull in 100k of bloat. 2) The C standard library is not a good module to be emulated. While the C standard library should be available via c.stdio, that's it. C file I/O is particularly slow due to the double buffering it requires. 3) Core library stuff should be easilly implementable on both win32 and linux. With those two covered, it shouldn't be too much trouble to take it anywhere. 4) Modules should be a thin veneer over operating system API's. This will alleviate the temptation of bypassing them and calling the OS directly. 5) Performance matters. 6) Size matters. 7) Make use of the in, out, invariant and unittest features, especially the unittest. 8) As always, be real careful about copyrights. A standard library that's encumbered by disinterested third party copyrights will be a boat anchor holding us all back. D needs to be IP clean, it's the right thing to do. When in any doubt, write it from scratch. 9) Put your name in the code you write! You'll be famous as one of the D pioneers! I think we can learn a lot from how the Python libraries are organized. Their creators seem to know what they're doing <g>. |
August 16, 2003 Re: Standard D Library | ||||
---|---|---|---|---|
| ||||
Posted in reply to Walter | Great I was wondering about this, I remember alot of activity but don't remember what became of it. I'd really like to see this started also, I can offer webspace, CVS and whatever else you need (within reason ;) ). I'd also like to contribute, there is alot of talent on this newsgroup who would be interested in this ? I'm not trying to elect myself as leader to this, I just want to see it get off the ground. Thanks, lets hear some ideas! Charles "Walter" <walter@digitalmars.com> wrote in message news:bhkq1t$1urm$1@digitaldaemon.com... > I want to encourage everyone to help out with the library. My primary focus, > as you all have guessed by now, is making the compiler itself the best it can be. Phobos has been a bit neglected as a result. I, of course, will take > on the task of the necessary runtime support for the language semantics, such as making sure the exception handling stack unwinder works. But the stuff that makes a library full and great, I'm not too good at. > > A couple philosophical points on what I think makes a good library: > > 1) Loose coupling. This is important so that small apps can be created. In Java, it turned out that every class was dependent on every other class, so > the smallest app pulled in the entire library. Library modules should be as > decoupled as practical. Calling a directory function shouldn't pull in 100k > of bloat. > > 2) The C standard library is not a good module to be emulated. While the C standard library should be available via c.stdio, that's it. C file I/O is particularly slow due to the double buffering it requires. > > 3) Core library stuff should be easilly implementable on both win32 and linux. With those two covered, it shouldn't be too much trouble to take it anywhere. > > 4) Modules should be a thin veneer over operating system API's. This will alleviate the temptation of bypassing them and calling the OS directly. > > 5) Performance matters. > > 6) Size matters. > > 7) Make use of the in, out, invariant and unittest features, especially the > unittest. > > 8) As always, be real careful about copyrights. A standard library that's encumbered by disinterested third party copyrights will be a boat anchor holding us all back. D needs to be IP clean, it's the right thing to do. When in any doubt, write it from scratch. > > 9) Put your name in the code you write! You'll be famous as one of the D pioneers! > > I think we can learn a lot from how the Python libraries are organized. Their creators seem to know what they're doing <g>. > > |
August 16, 2003 Re: Standard D Library | ||||
---|---|---|---|---|
| ||||
Posted in reply to Charles Sanders Attachments: | "Charles Sanders" <sanders-consulting@comcast.net> wrote in message news:bhm2ns$3dd$1@digitaldaemon.com... > Great I was wondering about this, I remember alot of activity but don't remember what became of it. > > I'd really like to see this started also, I can offer webspace, CVS and whatever else you need (within reason ;) ). I'd also like to contribute, there is alot of talent on this newsgroup who would be interested in this ? I always prefered perforce to cvs http://www.perforce.com/ as this is an open source project (does not need to be GPL but does have to contain "Redistribution and use in source and binary forms, with or without modification, are permitted" ) not sure if that is acceptable,Walter what where your plans for the phobos libs licence? > > I'm not trying to elect myself as leader to this, I just want to see it get > off the ground. I've started have a play getting some Java like Stream libs started as I find the phobos Stream too much like FILE *, and perfer the Java approach where InputStream is just that. but I've run into a few issues first wchar[] is not very well supported Exception for instance can not have a wchar[] msg seems to me that it would be best if all apis used wchar as char-> wchar ([] or not) can be performed without loss of information (the converse not). the wchar windows api calls is missing too (well as is a lot of the win32 API) that is solvable by using the ported headers I've done and getting them tested (I'm certain that there may be alignment and other errors in there there is nearly a meg of code however I do not believe that it is realy legal for me to redistribute the work I've done (Bill if your reading this, and want to sue me I'll only accept the summons if you deliver it in person!) (I've attached the MS SDK licence) from what I read I can redist modified code only if I can make an object lib (not realy helpful) Walter I assume you have a licence to redistribute the MS headers, does it cover redist of modified headers and does it extend to a) ppl outside your company b) the latest SDK ? otherwise the first task as I see it it so get a licence to port the MS headers without that we are dead in the water. (if case a false I wonder if we can become unpayed members of the DM staff to get around the licence agreement(s)). I have to revisit python to see how/what the layout is like but module and templates are causing me some grief. again I like the Java way, there is nothing worse (to me) than having to search for where something is. if I want the class phobos.io.InputStream ... I'd like to know A how to get it and B how to import it .. import phobos.io.InputStream; would seem logical or (import phobos.io; maybe) if I'm right about the D modules Object (which is defined in object.d) has the fully qualified name `object.Object` if I start putting each class into a separate file (and if this is going to be a multi developer open source lib I think you'll all agree that, that will be a lot nicer that a wacking great phobos/io.d (or whatever) file with all the stream and other io classes) say I use phobos/io/InputStream.d for InputStream etc its fully qualified name is then phobos.io.InputStream.InputStream; I could make is phobos/base/InputStream.d; => phobos.base.InputStream.InputStream; and have a alias in the phobos/io.d file (alias phobos.base.InputStream.InputStream InputStream;) but thats a lot of typing and prone to errors all to just get phobos.io.InputStream as a fully qualified name and to get the implementation into a file on its own. like templates (which are almost modules within modules) I think there there is too much depth in the D names, I think D needs a way to create a file that only contains one item, be that a template, class, struct or other. so import a.b.c; looks for a/b/c.d as it does now; only the item imported may be a.b.c rather than a.b.c.t.c or a.b.c.c etc; |
August 17, 2003 Re: Standard D Library | ||||
---|---|---|---|---|
| ||||
Posted in reply to Charles Sanders | You may try this instead of CVS: http://subversion.tigris.org/ Not a final version yet, but usable. Highlights: it has renames and atomic commit compared to CVS. "Charles Sanders" <sanders-consulting@comcast.net> wrote in message news:bhm2ns$3dd$1@digitaldaemon.com... > Great I was wondering about this, I remember alot of activity but don't remember what became of it. > > I'd really like to see this started also, I can offer webspace, CVS and whatever else you need (within reason ;) ). I'd also like to contribute, there is alot of talent on this newsgroup who would be interested in this ? > > I'm not trying to elect myself as leader to this, I just want to see it get off the ground. > > Thanks, lets hear some ideas! > > Charles > > > "Walter" <walter@digitalmars.com> wrote in message news:bhkq1t$1urm$1@digitaldaemon.com... > > I want to encourage everyone to help out with the library. My primary > focus, > > as you all have guessed by now, is making the compiler itself the best it can be. Phobos has been a bit neglected as a result. I, of course, will > take > > on the task of the necessary runtime support for the language semantics, such as making sure the exception handling stack unwinder works. But the stuff that makes a library full and great, I'm not too good at. > > > > A couple philosophical points on what I think makes a good library: > > > > 1) Loose coupling. This is important so that small apps can be created. In Java, it turned out that every class was dependent on every other class, > so > > the smallest app pulled in the entire library. Library modules should be > as > > decoupled as practical. Calling a directory function shouldn't pull in > 100k > > of bloat. > > > > 2) The C standard library is not a good module to be emulated. While the C standard library should be available via c.stdio, that's it. C file I/O is particularly slow due to the double buffering it requires. > > > > 3) Core library stuff should be easilly implementable on both win32 and linux. With those two covered, it shouldn't be too much trouble to take it anywhere. > > > > 4) Modules should be a thin veneer over operating system API's. This will alleviate the temptation of bypassing them and calling the OS directly. > > > > 5) Performance matters. > > > > 6) Size matters. > > > > 7) Make use of the in, out, invariant and unittest features, especially > the > > unittest. > > > > 8) As always, be real careful about copyrights. A standard library that's encumbered by disinterested third party copyrights will be a boat anchor holding us all back. D needs to be IP clean, it's the right thing to do. When in any doubt, write it from scratch. > > > > 9) Put your name in the code you write! You'll be famous as one of the D pioneers! > > > > I think we can learn a lot from how the Python libraries are organized. Their creators seem to know what they're doing <g>. > > > > > > |
August 17, 2003 Re: Standard D Library | ||||
---|---|---|---|---|
| ||||
Posted in reply to Mike Wynn Attachments:
| Perhaps what you want is akin to the ability to pick out one name from a module, like so: ========file A.d:=========== module A; class B {} ... ========file C.d:=========== module C; import A.B; // just bring in class B from module A Except you want to be able to do away with module A entirely. What if such a file were missing a module declaration, and the only name present in it matches the file name? ========file B.d:=========== class B {} ... ========file C.d:=========== module C; import B; // just bring in class B from B.d Hmm. It seems viable but I'm sure there would be other issues to work out. What if class B needs some "global" support declarations? A workaround for now might be public imports. ========file A.d:=========== module A; class B {} ... ========file Stuff.d:=========== public import A.B; ... ========file C.d:=========== module C; import Stuff.B; // just bring in class B from A.d, via public import in Stuff.d I seem to recall D used to have this behavior by default, and private imports were added to compensate. So this might still work, I haven't checked. You could pull in everything you need into one big library interface module, even though it actually lives in its own module in its own file. But it requires such a library interface module. That's not such a stiff requirement though, as this kind of thing would be mostly for library work anyway. Sean "Mike Wynn" <mike.wynn@l8night.co.uk> wrote in message news:bhme5o$jlf$1@digitaldaemon.com... like templates (which are almost modules within modules) I think there there is too much depth in the D names, I think D needs a way to create a file that only contains one item, be that a template, class, struct or other. so import a.b.c; looks for a/b/c.d as it does now; only the item imported may be a.b.c rather than a.b.c.t.c or a.b.c.c etc; |
August 17, 2003 Re: | ||||
---|---|---|---|---|
| ||||
Posted in reply to Walter | In article <bhknmd$1nqb$4@digitaldaemon.com>, Walter says... > > >"Les Baker" <lesbaker@innovaREMOVETHIS.net> wrote in message news:bgk875$e1r$1@digitaldaemon.com... >> > SDL bad. I don't like acronyms. They're all taken and they convey no information. >> >> FYI on a potential name collision too -- "SDL" is the acronym for Simple Directmedia Layer, a multimedia library for C. It also stands for System Design Language,a design notation still used in telecoms. >> >> I kinda like "Phobos" anyhow; it's creative and is a nice allusion to the "Digital Mars" name. I don't. It ties the name to DigitalMars, rendering it forever niche. If D is going to get more widespread usage it has to have a life outside of DigitalMars. -Andrew Marlow |
August 18, 2003 Re: Standard D Library | ||||
---|---|---|---|---|
| ||||
Posted in reply to Walter | Walter wrote: > I want to encourage everyone to help out with the library. My primary focus, > as you all have guessed by now, is making the compiler itself the best it > can be. Phobos has been a bit neglected as a result. I, of course, will take > on the task of the necessary runtime support for the language semantics, > such as making sure the exception handling stack unwinder works. But the > stuff that makes a library full and great, I'm not too good at. > > A couple philosophical points on what I think makes a good library: > > 1) Loose coupling. This is important so that small apps can be created. In > Java, it turned out that every class was dependent on every other class, so > the smallest app pulled in the entire library. Library modules should be as > decoupled as practical. Calling a directory function shouldn't pull in 100k > of bloat. Well if you build a library based on objects you will have branches of tight coupled classes. e.g all the List classes single linked, double linked etc will have features implemented in some base class. But I assume you were not talking about that kind of cohesion. > > 2) The C standard library is not a good module to be emulated. While the C > standard library should be available via c.stdio, that's it. C file I/O is > particularly slow due to the double buffering it requires. That is a very good suggestion IMHO. On the other hand many know that library regularly and know the Ins/Outs... > > 3) Core library stuff should be easilly implementable on both win32 and > linux. With those two covered, it shouldn't be too much trouble to take it > anywhere. Would you mind to explain what you understand under core libraries? Are you talking about well known datastructures? I can't see any problem with a library if it's fully implemented in D. A list implementation will work on "all the platforms" > > 4) Modules should be a thin veneer over operating system API's. This will > alleviate the temptation of bypassing them and calling the OS directly. This is a good idea. I think have something layered will work as usual. A very thin layer for "base services" and a lot of convenience libraries. > > 5) Performance matters. Definitly for a base library. > > 6) Size matters. Agreed. Anyway I would sacrify it quite bunch of the latter points for stability and even more important (IMHO) maintainebility. > > 7) Make use of the in, out, invariant and unittest features, especially the > unittest. Very very important. Don't forget the contracts! > > 8) As always, be real careful about copyrights. A standard library that's > encumbered by disinterested third party copyrights will be a boat anchor > holding us all back. D needs to be IP clean, it's the right thing to do. > When in any doubt, write it from scratch That is really a BIG problem. > > 9) Put your name in the code you write! You'll be famous as one of the D > pioneers! In my opinion D offers quite a lot for library development, but library development is time consuming and getting libaries consistent is really hard to get right. I suggest checking the naming conventions in Eiffel as a design starting point. I have spend quite some time on library development but are very short on time beeing able to spend on free work.... Regards Friedrich |
August 26, 2003 Re: Standard D Library | ||||
---|---|---|---|---|
| ||||
Posted in reply to Walter |
Walter wrote:
>
> I want to encourage everyone to help out with the library. My primary focus, as you all have guessed by now, is making the compiler itself the best it can be. Phobos has been a bit neglected as a result. I, of course, will take on the task of the necessary runtime support for the language semantics, such as making sure the exception handling stack unwinder works. But the stuff that makes a library full and great, I'm not too good at.
>
> A couple philosophical points on what I think makes a good library:
>
> 1) Loose coupling. This is important so that small apps can be created. In Java, it turned out that every class was dependent on every other class, so the smallest app pulled in the entire library. Library modules should be as decoupled as practical. Calling a directory function shouldn't pull in 100k of bloat.
>
> 2) The C standard library is not a good module to be emulated. While the C standard library should be available via c.stdio, that's it. C file I/O is particularly slow due to the double buffering it requires.
>
> 3) Core library stuff should be easilly implementable on both win32 and linux. With those two covered, it shouldn't be too much trouble to take it anywhere.
>
> 4) Modules should be a thin veneer over operating system API's. This will alleviate the temptation of bypassing them and calling the OS directly.
>
> 5) Performance matters.
>
> 6) Size matters.
>
> 7) Make use of the in, out, invariant and unittest features, especially the unittest.
>
> 8) As always, be real careful about copyrights. A standard library that's encumbered by disinterested third party copyrights will be a boat anchor holding us all back. D needs to be IP clean, it's the right thing to do. When in any doubt, write it from scratch.
>
> 9) Put your name in the code you write! You'll be famous as one of the D pioneers!
>
> I think we can learn a lot from how the Python libraries are organized. Their creators seem to know what they're doing <g>.
If I try to boil this down, I arrive at:
A) The primary design goal is efficiency. Priorities:
A.1 Unbloated Executables (thin wrappers to APIs, loose coupling)
A.2 Performance is more important than size (help the compiler / in out invariant)
A.3 Runtime Size is important, but less than performance
B) Secondary design goals
B.1 Keep Windows and Linux in mind and on par
B.2 Care about safety (unittests!)
B.3 Care about copyrights (in doubt? rewrite!)
Please correct me, where I'm wrong.
Where shall OO fit in? Sometimes objects and object hierarchies result in increased coupling and bloat.
--
Helmut Leitner leitner@hls.via.at Graz, Austria www.hls-software.com
|
Copyright © 1999-2021 by the D Language Foundation