www.digitalmars.com         C & C++   DMDScript  

digitalmars.D - Contributing to Phobos?

reply Arcane Jill <Arcane_member pathlink.com> writes:
Um ... is it possible to contribute to the Phobos library?

I ask because I am writing a package in D which implements unlimited-precision
integers. (It is NOT a wrapper around gmp - it is written natively in D, and
very extensively unittest-ed). I expect to be finished in a week or two,
although there will still be room for speed-up modifications.

Is there a way to contribute it to the public effort?

If not, should I just publish it on my own website and declare everything in my
own namespace (so, for example, you'd use something like:

       import arcane.mpi;

instead of
       import std.mpi;

..?) What's the story? How does this work? Is Phobos purely a proprietry thing or what? Someone please enlighten me. Arcane Jill PS. Is the name Deimos taken?
May 20 2004
next sibling parent reply Norbert Nemec <Norbert.Nemec gmx.de> writes:
Before taking contributions for the standard library, it should be made
clear what the development model there is. Adding something to "std" should
really be a step that is well considered. Only rock-solid designs should
enter std. Also, all parts of std should be tightly integrated. e.g: if
there is a library for unlimited-precision integers in std, it should be
made certain that every other part of std does fully cooperate with it,
etc.

Maybe, an additional contrib library should be opened? As a place where all
kinds of contributions are collected?

In any case: a clear model for developing an extensive library is crucial
for the language. Just consider Perl: The language is ugly like something,
but the CPAN definitely is worth quite bit.


Arcane Jill wrote:

 Um ... is it possible to contribute to the Phobos library?
 
 I ask because I am writing a package in D which implements
 unlimited-precision integers. (It is NOT a wrapper around gmp - it is
 written natively in D, and very extensively unittest-ed). I expect to be
 finished in a week or two, although there will still be room for speed-up
 modifications.
 
 Is there a way to contribute it to the public effort?
 
 If not, should I just publish it on my own website and declare everything
 in my own namespace (so, for example, you'd use something like:
 
       import arcane.mpi;

instead of
       import std.mpi;

..?) What's the story? How does this work? Is Phobos purely a proprietry thing or what? Someone please enlighten me. Arcane Jill PS. Is the name Deimos taken?

May 20 2004
next sibling parent reply Arcane Jill <Arcane_member pathlink.com> writes:
In article <c8iib6$q59$1 digitaldaemon.com>, Norbert Nemec says...
Before taking contributions for the standard library, it should be made
clear what the development model there is.

I didn't completely understand that. Could you elaborate please?
Adding something to "std" should
really be a step that is well considered. Only rock-solid designs should
enter std.

Well, I'm arrogant enough to believe that I have a rock solid design, but, that said, I'm quite willing to co-operate with efforts to integrate my stuff cleanly and make sure that everything works with everything else.
Also, all parts of std should be tightly integrated. e.g: if
there is a library for unlimited-precision integers in std, it should be
made certain that every other part of std does fully cooperate with it,
etc.

Do you mean, for example, that std.stream.Stream should have functions to read and write unlimited-precision integers, just as they have functions to read and write normal ones? That sort of thing would be beyond my control, but very easy for you guys to add, given my API.
Maybe, an additional contrib library should be opened? As a place where all
kinds of contributions are collected?

Maybe "Deimos" could be that place? If so, they could stay there until (if and when) the powers that be in D-land decide that it's worthy - at which point it could be moved from Deimos to Phobos. Would that be a good idea?
In any case: a clear model for developing an extensive library is crucial
for the language. Just consider Perl: The language is ugly like something,
but the CPAN definitely is worth quite bit.

Actually, the truth is though that I'm not writing this for glory, I'm writing it because I actuallly need to use it. (I'll be writing a crypto library later on, too). But ... I suspect that other people will find big integers useful, given the popularity of gmp on Linux. And I'm also being very careful to stick to they style guide, make full use of unit tests and contracts and so on. Arcane Jill
May 20 2004
next sibling parent reply J Anderson <REMOVEanderson badmama.com.au> writes:
Arcane Jill wrote:

Maybe "Deimos" could be that place? If so, they could stay there until (if and
when) the powers that be in D-land decide that it's worthy - at which point it
could be moved from Deimos to Phobos. Would that be a good idea?

  

www.dsource.org? It could be done in such a way that changed phobos files could be placed in deimos. For example if you needed to change string you'd add the module: module deimos.std.string; To deimos with the phobos like string. If that's ok to Walter of couse. Then a commitee (or whatever) and Walter could decide later what bits of code are good enough for phobos and beable to copy and paste the different segments. -- -Anderson: http://badmama.com.au/~anderson/
May 20 2004
next sibling parent DemmeGod <me demmegod.com> writes:
On Fri, 21 May 2004 00:20:48 +0800, J Anderson wrote:

 Arcane Jill wrote:
 
 
Maybe "Deimos" could be that place? If so, they could stay there until
(if and when) the powers that be in D-land decide that it's worthy - at
which point it could be moved from Deimos to Phobos. Would that be a good
idea?


  

www.dsource.org? It could be done in such a way that changed phobos files could be placed in deimos. For example if you needed to change string you'd add the module: module deimos.std.string; To deimos with the phobos like string. If that's ok to Walter of couse. Then a commitee (or whatever) and Walter could decide later what bits of code are good enough for phobos and beable to copy and paste the different segments.

There's also the licensing issue... As far as I know, the phobos license isn't open source, and still sort of up-in-the-air. Walter (and Matthew, I guess) need to fix this before these sort of contributions should occur. All they have to do is slap an F/OSS complaint license on it!
May 20 2004
prev sibling parent J C Calvarese <jcc7 cox.net> writes:
J Anderson wrote:
 Arcane Jill wrote:
 
 Maybe "Deimos" could be that place? If so, they could stay there until 
 (if and
 when) the powers that be in D-land decide that it's worthy - at which 
 point it
 could be moved from Deimos to Phobos. Would that be a good idea?

  

www.dsource.org? It could be done in such a way that changed phobos files could be placed in deimos. For example if you needed to change string you'd add the module: module deimos.std.string;

Great idea! We could also follow this convention... Phobos: std.string Deimos: etc.string (Walter has already said that "etc" was intended for items that might eventually be put into Phobos.)
 
 To deimos with the phobos like string.  If that's ok to Walter of 
 couse.  Then a commitee (or whatever) and Walter could decide later what 
 bits of code are good enough for phobos and beable to copy and paste the 
 different segments.

Right. And in the meantime, we could find these various items in one handy location, such as dsource (as you mentioned earlier). -- Justin (a/k/a jcc7) http://jcc_7.tripod.com/d/
May 20 2004
prev sibling next sibling parent reply Norbert Nemec <Norbert.Nemec gmx.de> writes:
Arcane Jill wrote:

 In article <c8iib6$q59$1 digitaldaemon.com>, Norbert Nemec says...
Before taking contributions for the standard library, it should be made
clear what the development model there is.

I didn't completely understand that. Could you elaborate please?

Basically I meant: * Who will hold the power over std? For the language specs and the compiler, this question is simply answered. Will Walter take care of the library in the same way? Will it be someone else? Will there be some group of people, sticking to a set of fixed design principles? * What about the contrib/etc/deimos library? CPAN for perl basically just is a pool of code snippets where people contribute and then, the responsibility is unclear. Should deimos be such a pool where everybody can contribute anything, or should there already be some preliminary check before something gets into deimos? Maybe, there should be two steps: One pool of unchecked, unmaintained code snippets and one library of checked and maintained code that is waiting to enter the standard library one day?
Adding something to "std" should
really be a step that is well considered. Only rock-solid designs should
enter std.

Well, I'm arrogant enough to believe that I have a rock solid design, but, that said, I'm quite willing to co-operate with efforts to integrate my stuff cleanly and make sure that everything works with everything else.

I don't know anything about your design and I have no reason to doubt it. My statement was absolutely general, and I'm pretty sure, nobody would question it... Anyhow: to make the statement even stronger, I would add, that even a collection of rocks does not make a good library, if the rocks don't fit together to form a building. But this, too, is just a general statement, and since you already talk about integration, I see no need to worry about this in the case of your code. Ciao, Nobbi
May 21 2004
parent DemmeGod <me demmegod.com> writes:
On Fri, 21 May 2004 09:46:24 +0200, Norbert Nemec wrote:
 
 Anyhow: to make the statement even stronger, I would add, that even a
 collection of rocks does not make a good library, if the rocks don't fit
 together to form a building. But this, too, is just a general statement,
 and since you already talk about integration, I see no need to worry about
 this in the case of your code.
 
 Ciao,
 Nobbi

By which I believe you meant to say: "Science is built up of facts, as a house is with stones. But a collection of facts is no more a science then a heap of stones is a house." -- Jules Henri Poincar And he's right. A bunch of modules that all work separately is nearly worthless. There is no avoiding library interdependence, the only question is that of the amount. Java and C++ stdlib seem to be mansions, so what size house are we looking for? Certainly not a caravan of RV's, as it sounds like some would have it! Each RV has it's own bed, TV, bathroom, ect... A luxurious as a mansion is, however, one cannot tour the country in a mansion. It is obvious that one cannot do anything small in Java (or C++ stdlibs, I'd imagine). {Edited to remove further superfluous prose} Bottom line: If it makes sense for a modules to utilize another module, the idea of independent modules shouldn't stop one from doing what makes the most sense design-wise. Jill should certainly use bigint in the crypto lib. That's what it's being made for! At what point is the line in the sand drawn?
May 21 2004
prev sibling parent "Walter" <newshound digitalmars.com> writes:
"Arcane Jill" <Arcane_member pathlink.com> wrote in message
news:c8iku8$u9i$1 digitaldaemon.com...
 Actually, the truth is though that I'm not writing this for glory, I'm

 it because I actuallly need to use it.

It's been my experience that such libraries needed for the author's own use tend to be much better than ones designed by the marketing department <g>.
 (I'll be writing a crypto library later
 on, too). But ... I suspect that other people will find big integers

 given the popularity of gmp on Linux. And I'm also being very careful to

 to they style guide, make full use of unit tests and contracts and so on.

I think you'll do just fine around here <g>. Glad to have you with us.
May 21 2004
prev sibling next sibling parent reply Andy Friesen <andy ikagames.com> writes:
Norbert Nemec wrote:

 Also, all parts of std should be tightly integrated. e.g: if
 there is a library for unlimited-precision integers in std, it should be
 made certain that every other part of std does fully cooperate with it,
 etc.

The Phobos philosophy <http://digitalmars.com/d/phobos.html> seems to favour low coupling over "tight integration". (I never liked that term; I always hear/read it and think "hopelessly interdependant") -- andy
May 20 2004
next sibling parent reply "Matthew" <matthew.hat stlsoft.dot.org> writes:
 Norbert Nemec wrote:

 Also, all parts of std should be tightly integrated. e.g: if
 there is a library for unlimited-precision integers in std, it should be
 made certain that every other part of std does fully cooperate with it,
 etc.

The Phobos philosophy <http://digitalmars.com/d/phobos.html> seems to favour low coupling over "tight integration". (I never liked that term; I always hear/read it and think "hopelessly interdependant")

I agree completely. One of the things wrong with the C++ standard library is all the interdependence. I've just spent 48 hours adding a new Shell Extension (http://shellext.com/) and most of the effort was devoted to being independent of all the C++ gunk that the compiler thought I needed but I knew that I didn't. The last thing we want is a Phobos where every type is coupled with every other. There are plenty of other ways of designing libraries such that this does not need to happen.
May 20 2004
parent reply DemmeGod <me demmegod.com> writes:
I'm not familiar with the C++ standard libaray, only the Java libraries. 
How do they compare on this front?  That is, would you say that the Java
libs have interdependence issues like the C++ std libs?

On Fri, 21 May 2004 15:38:55 +1000, Matthew wrote:

 Norbert Nemec wrote:

 Also, all parts of std should be tightly integrated. e.g: if there is
 a library for unlimited-precision integers in std, it should be made
 certain that every other part of std does fully cooperate with it,
 etc.

The Phobos philosophy <http://digitalmars.com/d/phobos.html> seems to favour low coupling over "tight integration". (I never liked that term; I always hear/read it and think "hopelessly interdependant")

I agree completely. One of the things wrong with the C++ standard library is all the interdependence. I've just spent 48 hours adding a new Shell Extension (http://shellext.com/) and most of the effort was devoted to being independent of all the C++ gunk that the compiler thought I needed but I knew that I didn't. The last thing we want is a Phobos where every type is coupled with every other. There are plenty of other ways of designing libraries such that this does not need to happen.

May 20 2004
next sibling parent "Matthew" <matthew.hat stlsoft.dot.org> writes:
There's a long answer, and a short answer, and they're both unprintable. ;/

D does seek, and continues to seek, low coupling, low overhead, high efficiency,
none of which apply to Java, and only one of which applies to most C++
libraries.


"DemmeGod" <me demmegod.com> wrote in message
news:pan.2004.05.21.06.59.46.427053 demmegod.com...
 I'm not familiar with the C++ standard libaray, only the Java libraries.
 How do they compare on this front?  That is, would you say that the Java
 libs have interdependence issues like the C++ std libs?

 On Fri, 21 May 2004 15:38:55 +1000, Matthew wrote:

 Norbert Nemec wrote:

 Also, all parts of std should be tightly integrated. e.g: if there is
 a library for unlimited-precision integers in std, it should be made
 certain that every other part of std does fully cooperate with it,
 etc.

The Phobos philosophy <http://digitalmars.com/d/phobos.html> seems to favour low coupling over "tight integration". (I never liked that term; I always hear/read it and think "hopelessly interdependant")

I agree completely. One of the things wrong with the C++ standard library is all the interdependence. I've just spent 48 hours adding a new Shell Extension (http://shellext.com/) and most of the effort was devoted to being independent of all the C++ gunk that the compiler thought I needed but I knew that I didn't. The last thing we want is a Phobos where every type is coupled with every other. There are plenty of other ways of designing libraries such that this does not need to happen.


May 21 2004
prev sibling parent reply "Walter" <newshound digitalmars.com> writes:
"DemmeGod" <me demmegod.com> wrote in message
news:pan.2004.05.21.06.59.46.427053 demmegod.com...
 I'm not familiar with the C++ standard libaray, only the Java libraries.
 How do they compare on this front?  That is, would you say that the Java
 libs have interdependence issues like the C++ std libs?

Things may have changed since I last looked at Java, but in building a runtime linkable library for Java native apps, I discovered that using any Java runtime library function wound up pulling everything else in one way or another. The end result was it was better to make the Java runtime into a monolithic DLL. A similar problem seems to happen with C++ <iostream>. I don't want that to happen with Phobos.
May 21 2004
next sibling parent "Matthew" <matthew.hat stlsoft.dot.org> writes:
"Walter" <newshound digitalmars.com> wrote in message
news:c8kfi7$26a9$1 digitaldaemon.com...
 "DemmeGod" <me demmegod.com> wrote in message
 news:pan.2004.05.21.06.59.46.427053 demmegod.com...
 I'm not familiar with the C++ standard libaray, only the Java libraries.
 How do they compare on this front?  That is, would you say that the Java
 libs have interdependence issues like the C++ std libs?

Things may have changed since I last looked at Java, but in building a runtime linkable library for Java native apps, I discovered that using any Java runtime library function wound up pulling everything else in one way or another. The end result was it was better to make the Java runtime into a monolithic DLL. A similar problem seems to happen with C++ <iostream>. I don't want that to happen with Phobos.

I think we should stipulate right now that it must not.
May 21 2004
prev sibling parent reply Kevin Bealer <Kevin_member pathlink.com> writes:
In article <c8kfi7$26a9$1 digitaldaemon.com>, Walter says...
"DemmeGod" <me demmegod.com> wrote in message
news:pan.2004.05.21.06.59.46.427053 demmegod.com...
 I'm not familiar with the C++ standard libaray, only the Java libraries.
 How do they compare on this front?  That is, would you say that the Java
 libs have interdependence issues like the C++ std libs?

Things may have changed since I last looked at Java, but in building a runtime linkable library for Java native apps, I discovered that using any Java runtime library function wound up pulling everything else in one way or another. The end result was it was better to make the Java runtime into a monolithic DLL. A similar problem seems to happen with C++ <iostream>. I don't want that to happen with Phobos.

The flip side of this is the annoyance in using C++ that if you want to use string, you need to specify .c_str() everywhere. For example: string fn("somefile.txt"); string ln; // this is illegal, you can work around it with c_str(); ifstream nfile(fn); // This is also unsupported. Work around is uglier than c_str(), // and requires a number of unnecessary allocations, copies and calls. nfile.getline(line, '\n'); It would be great to avoid this issue. Personally I would be willing to tolerate tight coupling (for std modules) rather than this missing function that is designed to avoid it (often unsuccessfully). But I think there are solutions to both and with larger libs it is critical to do so. 1. Maybe some kind of blessed memento patterns and interfaces: Instead of providing (as C++) standard base classes for various hierarchies, provide a "standard interface" library. Interfaces providing standard signatures for every useful collaboration would be provided. The "substantial" individual modules would only be tied to the interface module. 2. Another approach would be an enhancement to the module system: modules could define a set of "appendixes" that only get pulled in if another module is available. Thus, I could define an editor widget, with an appendix for a font library. If the font library exists, the appendix is instantiated. I suspect that #2 is highly impractical implementation wise, but I'm not really certain about it. Kevin
May 21 2004
parent "Matthew" <matthew.hat stlsoft.dot.org> writes:
http://www.cuj.com/documents/s=8681/cuj0308wilson/

"Kevin Bealer" <Kevin_member pathlink.com> wrote in message
news:c8m29v$1gtj$1 digitaldaemon.com...
 In article <c8kfi7$26a9$1 digitaldaemon.com>, Walter says...
"DemmeGod" <me demmegod.com> wrote in message
news:pan.2004.05.21.06.59.46.427053 demmegod.com...
 I'm not familiar with the C++ standard libaray, only the Java libraries.
 How do they compare on this front?  That is, would you say that the Java
 libs have interdependence issues like the C++ std libs?

Things may have changed since I last looked at Java, but in building a runtime linkable library for Java native apps, I discovered that using any Java runtime library function wound up pulling everything else in one way or another. The end result was it was better to make the Java runtime into a monolithic DLL. A similar problem seems to happen with C++ <iostream>. I don't want that to happen with Phobos.

The flip side of this is the annoyance in using C++ that if you want to use string, you need to specify .c_str() everywhere. For example: string fn("somefile.txt"); string ln; // this is illegal, you can work around it with c_str(); ifstream nfile(fn); // This is also unsupported. Work around is uglier than c_str(), // and requires a number of unnecessary allocations, copies and calls. nfile.getline(line, '\n'); It would be great to avoid this issue. Personally I would be willing to tolerate tight coupling (for std modules) rather than this missing function

 is designed to avoid it (often unsuccessfully).  But I think there are

 to both and with larger libs it is critical to do so.

 1. Maybe some kind of blessed memento patterns and interfaces:  Instead of
 providing (as C++) standard base classes for various hierarchies, provide a
 "standard interface" library.  Interfaces providing standard signatures for
 every useful collaboration would be provided.  The "substantial" individual
 modules would only be tied to the interface module.

 2. Another approach would be an enhancement to the module system: modules could
 define a set of "appendixes" that only get pulled in if another module is
 available.  Thus, I could define an editor widget, with an appendix for a font
 library.  If the font library exists, the appendix is instantiated.

 I suspect that #2 is highly impractical implementation wise, but I'm not really
 certain about it.

 Kevin

May 21 2004
prev sibling parent reply Norbert Nemec <Norbert.Nemec gmx.de> writes:
Andy Friesen wrote:

 Norbert Nemec wrote:
 
 Also, all parts of std should be tightly integrated. e.g: if
 there is a library for unlimited-precision integers in std, it should be
 made certain that every other part of std does fully cooperate with it,
 etc.

The Phobos philosophy <http://digitalmars.com/d/phobos.html> seems to favour low coupling over "tight integration". (I never liked that term; I always hear/read it and think "hopelessly interdependant")

Well, true, naming something differently immediately makes it look different. Maybe an example might help in clarifying my point: Using the C++ library, I always found it somewhat enerving, that different parts seem to have been developed ignorant of each other. E.g.: you have that whole iostream block and the C++-strings. Obviously, both handle the same kind of data: character strings/streams. Still, iostreams is mainly built upon the char* data type, making it necessary to convert back and forth ever so often. I still believe that the standard library should be "tightly integrated", or, as you put it "hopelessly interdependant". If one part of the library implements powerful containers, why shouldn't another part make use of these? If there is well-designed string-handling in one part of the library, why should the IO-library ignore it and define everything anew? Of course, the dependencies should be clearly defined. The standard library should be modular where it makes sense, but these modules definitely should not be too small and should not be split apart at the cost of reimplementation and limited interoperability.
May 21 2004
parent Andy Friesen <andy ikagames.com> writes:
Norbert Nemec wrote:

 I still believe that the standard library should be "tightly integrated",
 or, as you put it "hopelessly interdependant". If one part of the library
 implements powerful containers, why shouldn't another part make use of
 these? If there is well-designed string-handling in one part of the
 library, why should the IO-library ignore it and define everything anew?
 
 Of course, the dependencies should be clearly defined. The standard library
 should be modular where it makes sense, but these modules definitely should
 not be too small and should not be split apart at the cost of
 reimplementation and limited interoperability.

I'm not arguing for absolutism; that's rarely the answer. It's inevitable that some bits of Phobos will depend on others, but care should be taken, for instance, to ensure that using std.stream does not require std.bigint to be linked in. I once read a newsgroup posting someplace (I wish I could find the link) that showed what the JVM went through to execute 'Hello World'. It literally spanned hundreds of classes. -- andy
May 21 2004
prev sibling next sibling parent reply Sean Kelly <sean ffwd.cx> writes:
Norbert Nemec wrote:

 Before taking contributions for the standard library, it should be made
 clear what the development model there is. Adding something to "std" should
 really be a step that is well considered. Only rock-solid designs should
 enter std. Also, all parts of std should be tightly integrated. e.g: if
 there is a library for unlimited-precision integers in std, it should be
 made certain that every other part of std does fully cooperate with it,
 etc.

I agree completely. And this has actually been my greatest concern with the rush to 1.0. It will be much easier to add new features a bit late in the game then try to pull out or alter ones that were added a bit prematurely. Java had this problem in spades, which was a major obstacle to its widespread acceptance.
 Maybe, an additional contrib library should be opened? As a place where all
 kinds of contributions are collected?

The C++ community has this with Boost and I think it's a fantastic idea. Submissions get excellent peer review and tons of user testing before any chance of inclusion into the C++ standard library. And while D doesn't have a standards body to contend with, I think a similar model would work quite well.
 In any case: a clear model for developing an extensive library is crucial
 for the language. Just consider Perl: The language is ugly like something,
 but the CPAN definitely is worth quite bit.

I think D needs a focus. Much of the C++ standard library is almost a proof of concept for generic programming, and it's easy to see which components were standardized before and after this focus occurred. I can't help but wonder if streams would have been different had they been designed today, for example. But the same thing needs to happen with D. Is the goal merely to improve upon exsting techniques? And if so, which ones? D is in an odd situation where it's gathering programmers from two very different backgrounds--Java and C++--and each carries an entirely different mindset. As a C++ person I find myself opposing the folks who seem to want D to be a better Java, or to replicate Java libraries in D. But my criticisms are half-baked because my perspective is obviously biased as well. So what are the design goals for D? In addition to coding standards, I feel there are design standard that Phobos submissions should conform to. Sean
May 20 2004
parent reply J C Calvarese <jcc7 cox.net> writes:
Sean Kelly wrote:
 Norbert Nemec wrote:
 
 Before taking contributions for the standard library, it should be made
 clear what the development model there is. Adding something to "std" 
 should
 really be a step that is well considered. Only rock-solid designs should
 enter std. Also, all parts of std should be tightly integrated. e.g: if
 there is a library for unlimited-precision integers in std, it should be
 made certain that every other part of std does fully cooperate with it,
 etc.

I agree completely. And this has actually been my greatest concern with the rush to 1.0. It will be much easier to add new features a bit late

I could be entirely wrong, but I believe the idea is that D 1.0 means the specification is set in stone. I think Phobos would continue to be in flux for a while.
 in the game then try to pull out or alter ones that were added a bit 
 prematurely.  Java had this problem in spades, which was a major 
 obstacle to its widespread acceptance.
 
 Maybe, an additional contrib library should be opened? As a place 
 where all
 kinds of contributions are collected?

The C++ community has this with Boost and I think it's a fantastic idea. Submissions get excellent peer review and tons of user testing before any chance of inclusion into the C++ standard library. And while D doesn't have a standards body to contend with, I think a similar model would work quite well.
 In any case: a clear model for developing an extensive library is crucial
 for the language. Just consider Perl: The language is ugly like 
 something,
 but the CPAN definitely is worth quite bit.

I think D needs a focus.

Walter is focused on implemented the compiler. Many of the rest of us are focused on requesting new features for said compiler. :) Fortunately, Walter's concentration power is stronger than our distraction power. Otherwise, we would have a compiler that looks great on paper, but won't be available until 2010 (at the earliest).
 
 Much of the C++ standard library is almost a proof of concept for 
 generic programming, and it's easy to see which components were 
 standardized before and after this focus occurred.  I can't help but 
 wonder if streams would have been different had they been designed 
 today, for example.
 
 But the same thing needs to happen with D.  Is the goal merely to 
 improve upon exsting techniques?  And if so, which ones?  D is in an odd 
 situation where it's gathering programmers from two very different 
 backgrounds--Java and C++--and each carries an entirely different 
 mindset.  As a C++ person I find myself opposing the folks who seem to 
 want D to be a better Java, or to replicate Java libraries in D.  But my 
 criticisms are half-baked because my perspective is obviously biased as 
 well.  So what are the design goals for D?  In addition to coding 
 standards, I feel there are design standard that Phobos submissions 
 should conform to.

I've noticed a certain C++ vs. Java undertone to some of these discussions, too. "Well, this is how I program in Java, so we need to add a feature to D to facilitate this." or... "Well, D needs to overload operators ad infinitum because that's what I like to do in C++." When you refer to coding standards, do you mean things like "avoid using goto" or "place your braces {} like this ..."? Both types of standards are useful (though usage would be more essential than style), but both would probably generate some controversy.
 
 Sean 

-- Justin (a/k/a jcc7) http://jcc_7.tripod.com/d/
May 20 2004
parent Sean Kelly <sean f4.ca> writes:
J C Calvarese wrote:
 
 I could be entirely wrong, but I believe the idea is that D 1.0 means 
 the specification is set in stone. I think Phobos would continue to be 
 in flux for a while.

Works for me, asmy primary concern was that we not be too hasty with Phobos.
 When you refer to coding standards, do you mean things like "avoid using 
 goto" or "place your braces {} like this ..."? Both types of standards 
 are useful (though usage would be more essential than style), but both 
 would probably generate some controversy.

Not really. I am more interested in having the interface for all Phobos stuff be consistent and in keeping with some basic design requirements. The Phobos philosophy covers the basics pretty well, but I'd like something a bit more thorough. Basically, I'd like Phobos to feel like it was designed by a single team of programmers and not cobbled together from the best stuff that was submitted. It's perhaps a small difference, but IMO an important one. This is what I was getting at with all that talk about a focus. I thought that if there were a basic programming philosophy that D/Phobos were targeting then consistency might follow naturally. Sean
May 21 2004
prev sibling parent "Walter" <newshound digitalmars.com> writes:
"Norbert Nemec" <Norbert.Nemec gmx.de> wrote in message
news:c8iib6$q59$1 digitaldaemon.com...
 Maybe, an additional contrib library should be opened? As a place where

 kinds of contributions are collected?

That's what the etc package is for.
May 21 2004
prev sibling parent reply Stewart Gordon <smjg_1998 yahoo.com> writes:
Arcane Jill wrote:

<snip>
 If not, should I just publish it on my own website and declare everything in my
 own namespace (so, for example, you'd use something like:

Several of us have our websites where we keep our homemade libraries and stuff. For example, mine is http://smjg.port5.com/pr/d/. You might as well do the same.
      import arcane.mpi;

instead of
      import std.mpi;


Are we still talking of your unlimited-precision integer module here? Better tell everyone it isn't to do with Message Passing Interface.... <snip>
 PS. Is the name Deimos taken?

I don't know where my mind had gone, besides into thinking Phobos must be Greek for fear. But quite what the lib's afraid of, I never figured.... :-) Stewart. -- My e-mail is valid but not my primary mailbox, aside from its being the unfortunate victim of intensive mail-bombing at the moment. Please keep replies on the 'group where everyone may benefit.
May 20 2004
next sibling parent reply Arcane Jill <Arcane_member pathlink.com> writes:
In article <c8juo0$1aa2$1 digitaldaemon.com>, J C Calvarese says...

We could also follow this convention...

Phobos: std.string
Deimos: etc.string

(Walter has already said that "etc" was intended for items that might 
eventually be put into Phobos.)

and In article <c8ir1g$1cc6$1 digitaldaemon.com>, Stewart Gordon says...
Are we still talking of your unlimited-precision integer module here? 
Better tell everyone it isn't to do with Message Passing Interface....

Okay. I shall change my module name from "arcane.mpi" to "etc.bigint" (unless anyone has a better name). I wouldn't like this module to get confused with Message Passing Interface! Besides which - module names should really be descriptive, which "mpi" isn't. If the whole Deimos concept isn't set up and running by the time I've finished (say, a week or two from now) I shall probably consult with this list to try to make it happen, with the assistance of others here. I think it is an excellent idea. Jill
May 21 2004
parent "Matthew" <matthew.hat stlsoft.dot.org> writes:
"Arcane Jill" <Arcane_member pathlink.com> wrote in message
news:c8kaks$1u9k$1 digitaldaemon.com...
 In article <c8juo0$1aa2$1 digitaldaemon.com>, J C Calvarese says...

We could also follow this convention...

Phobos: std.string
Deimos: etc.string

(Walter has already said that "etc" was intended for items that might
eventually be put into Phobos.)

and In article <c8ir1g$1cc6$1 digitaldaemon.com>, Stewart Gordon says...
Are we still talking of your unlimited-precision integer module here?
Better tell everyone it isn't to do with Message Passing Interface....

Okay. I shall change my module name from "arcane.mpi" to "etc.bigint"

I think that is a mistake. You're far better off sticking with something unique to yourself at this point
May 21 2004
prev sibling parent reply A. Stevenson <alexstev AT uk.ibm.com> <A._member pathlink.com> writes:
In article <c8ir1g$1cc6$1 digitaldaemon.com>, Stewart Gordon says...
 PS. Is the name Deimos taken?

I don't know where my mind had gone, besides into thinking Phobos must be Greek for fear. But quite what the lib's afraid of, I never figured.... :-) Stewart.

Though it's nice to use the names of the Martian moons (Phobos and Deimos) for Digital Mars stuff, what does it say about D that our standard libraries are called 'fear' and 'dread' in Greek?
May 21 2004
next sibling parent "Walter" <newshound digitalmars.com> writes:
"A. Stevenson" <alexstev AT uk.ibm.comA._member pathlink.com> wrote in
message news:c8kot2$2kbe$1 digitaldaemon.com...
 Though it's nice to use the names of the Martian moons (Phobos and Deimos)

 Digital Mars stuff, what does it say about D that our standard libraries

 called 'fear' and 'dread' in Greek?

Cool! <g> (I, for one, am bored with TLA's and bland corporate committee sounding names.)
May 21 2004
prev sibling parent "Matthew" <matthew.hat stlsoft.dot.org> writes:
"A. Stevenson" <alexstev AT uk.ibm.comA._member pathlink.com> wrote in message
news:c8kot2$2kbe$1 digitaldaemon.com...
 In article <c8ir1g$1cc6$1 digitaldaemon.com>, Stewart Gordon says...
 PS. Is the name Deimos taken?

I don't know where my mind had gone, besides into thinking Phobos must be Greek for fear. But quite what the lib's afraid of, I never figured.... :-) Stewart.

Though it's nice to use the names of the Martian moons (Phobos and Deimos) for Digital Mars stuff, what does it say about D that our standard libraries are called 'fear' and 'dread' in Greek?

I like it. :)
May 21 2004