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