>Yes, it is intentional behavior of the linker, which is a standard linker. To override part of the functionality of a library, the right way to do it is to replace the entire module or derive from a class.
Right.  I brought this point up though because mixing source and declarations in the same file, doing away with includes, gives the impression that all the code for a D module needs to be in one place.  Thankfully with your present implementation, D modules can be defined piecewise, and a D module can map to several .obj modules.  And as you point out, as long as you're overloading at the .obj module granularity it's fine.  I think it is important that this be specified in the D spec so that future implementors don't try and outsmart us by "simplifying" things to D module = .obj module.

Here's a concrete example that fleshes this out:
In embedded systems, it is common to have a framework with a few stub functions
that are specific to your custom hardware.  These low level functions like
timers and basic serial I/O are usually provided by the end user.  In old school
C, these functions were each put in their own .obj module, and the end user
could put his own putchar/getchar or whathaveyou on the link line and customize
the framework behavior.  In this situation, inheritence is out because you
probably don't want to require that the garbage collector be running before you
can output debug messages.  You could stick with the extern "C" functions each
in their own object module, but I would like to see them implemented in D,
having the scope of the D module, including access to variables/functions
without requiring a friend relationship.  This is possible the way D is
currently implemented--and I'm thankful for it.

This is almost a separate thread, but implicit in the above paragraph was the idea that there is a subset of D that doesn't require a garbage collector.  This is absolutely essential* for doing embedded systems work.  I am making the naive assumption that as long as you don't dynamically allocate anything, the collector is not needed.  Is this true?  Can this be spelled out in the spec as well?

(*) This is especially true when porting a framework over to an untested piece of hardware; you want as little as possible getting in the way of your first effort.

One last thing on this, I realize that most of this goes away if you just have two separate D modules, both importing each other.  And that may even be a cleaner design decision for some applications.  I wasn't arguing that piecewise module definition was better, or right, just that it is useful and should be kept.  And if it is kept--acknowledged in the spec.

"Joe Battelle" <Joe_member@pathlink.com> wrote in message news:ajjpkv$2ami$1@digitaldaemon.com...
> This is almost a separate thread, but implicit in the above paragraph was
the
> idea that there is a subset of D that doesn't require a garbage collector.
This
> is absolutely essential* for doing embedded systems work.  I am making the
naive
> assumption that as long as you don't dynamically allocate anything, the collector is not needed.  Is this true?  Can this be spelled out in the
spec as
> well?

Yes, it is true. In fact, you can malloc/free objects (this is how the gc
bootstraps itself!).

"Joe Battelle" <Joe_member@pathlink.com> wrote in message news:ajjqp0$2bst$1@digitaldaemon.com...
> One last thing on this, I realize that most of this goes away if you just
have
> two separate D modules, both importing each other.  And that may even be a cleaner design decision for some applications.  I wasn't arguing that
piecewise
> module definition was better, or right, just that it is useful and should
be
> kept.  And if it is kept--acknowledged in the spec.

I think you're right.

On Sat, 17 Aug 2002 09:35:04 -0700 "Walter" <walter@digitalmars.com> wrote:

> Yes, it is true. In fact, you can malloc/free objects (this is how the gc
> bootstraps itself!).

But don't dynamic arrays use GC to allocate memory?

"Pavel Minayev" <evilone@omen.ru> wrote in message news:CFN37485980272581@news.digitalmars.com...
> On Sat, 17 Aug 2002 09:35:04 -0700 "Walter" <walter@digitalmars.com>
wrote:
> > Yes, it is true. In fact, you can malloc/free objects (this is how the
gc
> > bootstraps itself!).
> But don't dynamic arrays use GC to allocate memory?

Yes, but you can malloc a dynamic array:

    char *p = (char *)malloc(size);
    char[] a = p[0 .. size];

On Sat, 17 Aug 2002 21:34:54 -0700 "Walter" <walter@digitalmars.com> wrote:

> Yes, but you can malloc a dynamic array:
> 
>     char *p = (char *)malloc(size);
>     char[] a = p[0 .. size];

Yes, you can. But you can't use almost any char[] functions - toString(), regexp module... many others which allocate temporary char[] arrays inside which you don't know about. You either have to look the code for every function you use, to see if it uses dynamic arrays, or to use only API calls.

"Pavel Minayev" <evilone@omen.ru> wrote in message news:CFN374865090227199@news.digitalmars.com...
> On Sat, 17 Aug 2002 21:34:54 -0700 "Walter" <walter@digitalmars.com>
wrote:
> > Yes, but you can malloc a dynamic array:
> >     char *p = (char *)malloc(size);
> >     char[] a = p[0 .. size];
> Yes, you can. But you can't use almost any char[] functions - toString(), regexp module... many others which allocate temporary char[] arrays inside which you don't know about. You either have to look the code for every function you use, to see if it uses dynamic arrays, or to use only API calls.

That's right, you'll likely need to use your own library code.