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

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?

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?

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

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

"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)
for
> Digital Mars stuff, what does it say about D that our standard libraries
are
> called 'fear' and 'dread' in Greek?

Cool! <g>

(I, for one, am bored with TLA's and bland corporate committee sounding
names.)

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

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

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