> 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.

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.

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

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.

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.
>

"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

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

"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
writing
> 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
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.

I think you'll do just fine around here <g>. Glad to have you with us.

"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
all
> kinds of contributions are collected?

That's what the etc package is for.

"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.