Just noticed this in the specification:

"Ambiguities are illegal, and can be resolved by explicitly qualifying the symbol with the module name."

Ah, how I do hate this thing! First seen (by me) in C++ namespaces, it always annoyed after Pascal's "overriding" - when identifiers of unit listed later replace all matching from ealier units. This is especially useful when writing "patch" libraries: suppose somebody had written an enchanced, high-precision "Trig" trigonometry library for D. So, to upgrade your program (which could be thousands lines of code) with module overriding, you just add the Trig module _after_ the Math, and all those sines and cosines get replaced:

    import Math, Trig;   // both contain sin()
    ...
    y = sin(sqrt(x));    // equals Trig.sin(Math.sqrt(x))

On other hand, this could result in mistakes if two modules have matching identifiers and one is silently used instead of another. So maybe it's better to introduce some kind of way to tell the compiler which module can override others:

    import Math, override Trig;

Or maybe this all isn't even worth implementing... whatever.

Thoughts?

"Pavel Minayev" <evilone@omen.ru> wrote in message news:9tdv0l$jur$1@digitaldaemon.com...
> Just noticed this in the specification:
>
> "Ambiguities are illegal, and can be resolved by explicitly qualifying the symbol with the module name."
>
> Ah, how I do hate this thing! First seen (by me) in C++ namespaces, it always annoyed after Pascal's "overriding" - when identifiers of unit listed later replace all matching from ealier units. This is especially useful when writing "patch" libraries: suppose somebody had written an enchanced, high-precision "Trig" trigonometry library for D. So, to upgrade your program (which could be thousands lines of code) with module overriding, you just add the Trig module _after_ the Math, and all those sines and cosines get replaced:
>
>     import Math, Trig;   // both contain sin()
>     ...
>     y = sin(sqrt(x));    // equals Trig.sin(Math.sqrt(x))
>
> On other hand, this could result in mistakes if two modules have matching identifiers and one is silently used instead of another. So maybe it's better to introduce some kind of way to tell the compiler which module can override others:
>
>     import Math, override Trig;
>
> Or maybe this all isn't even worth implementing... whatever.
>
> Thoughts?

I am uncomfortable with the idea that lexically following imports override previous ones. My usual practice with C is to avoid any order dependencies (especially hidden ones).

"Walter" <walter@digitalmars.com> wrote in message news:9te4gc$njn$5@digitaldaemon.com...

> I am uncomfortable with the idea that lexically following imports override previous ones. My usual practice with C is to avoid any order dependencies (especially hidden ones).

Well there is comma-operator which is order-dependant... And, BTW, as I said there must probably be the way to indicate explicitly if module overrides previous ones.

Walter wrote:
> 
> "Pavel Minayev" <evilone@omen.ru> wrote in message news:9tdv0l$jur$1@digitaldaemon.com...
> > So maybe it's better to introduce some kind of
> > way to tell the compiler which module can override others:
> >
> >     import Math, override Trig;
> >
> > Or maybe this all isn't even worth implementing... whatever.
> >
> > Thoughts?
> 
> I am uncomfortable with the idea that lexically following imports override previous ones. My usual practice with C is to avoid any order dependencies (especially hidden ones).

I'm with Pavel on this one. Suppose you need to override a really fundamental part of a very standard library? Obviously, you want the library to be fine-grained enough for this not to come up too often, but the Math/Trig example is a reasonable one. Explicitly requesting linkage overrides seems a good compromise.

Mind you, I did have to replace a memory manager in C/C++ this weekend, so I might be a little biased.

-RB

Russell Borogove wrote:
> 
> Walter wrote:
> >
> > "Pavel Minayev" <evilone@omen.ru> wrote in message news:9tdv0l$jur$1@digitaldaemon.com...
> > > So maybe it's better to introduce some kind of
> > > way to tell the compiler which module can override others:
> > >
> > >     import Math, override Trig;
> > >
> > > Or maybe this all isn't even worth implementing... whatever.
> > >
> > > Thoughts?
> >
> > I am uncomfortable with the idea that lexically following imports override previous ones. My usual practice with C is to avoid any order dependencies (especially hidden ones).
> 
> I'm with Pavel on this one. Suppose you need to override a really fundamental part of a very standard library? Obviously, you want the library to be fine-grained enough for this not to come up too often, but the Math/Trig example is a reasonable one. Explicitly requesting linkage overrides seems a good compromise.
> 
> Mind you, I did have to replace a memory manager in C/C++ this weekend, so I might be a little biased.

	I second this, but only half way.  (Is that a first?)  I think the trig
example is a great reason why we need to be able to override.  The
memory management case is great too.
	On the other hand, I don't think it should be allowed by accident. It
would be way to easy to get clobbered like so:

     import Faith;  // put a little love in it
     import Math;   // but do it by the numbers
     ...
     if(sin(t)){  // this is truly a sin... err a sine
          ...
     }

If there is an ambiguity I thing the programmer should have to resolve it.  For the Trig case I would say make the programmer sort out the ambiguity like so:

     import Math;
     import Trig;
     using Trig.sin;
     y = sin(sqrt(x));    // equals Trig.sin(Math.sqrt(x))

I believe D has something like using or with already.  If this type of use were legal then there would be no ambiguity and the maintainer only needs to add one line of code (aside from the new import) to achieve that.  Readability fascists might gripe, but in all honesty I believe it may improve module readability.

Dan

"a" <a@b.c> wrote in message news:3BFF3A7D.EF790027@b.c...

> I second this, but only half way.  (Is that a first?)  I think the trig
> example is a great reason why we need to be able to override.  The
> memory management case is great too.
> On the other hand, I don't think it should be allowed by accident. It

I proposed this already:

import Math, Trig;    // sin() is not overriden
import Math, override Trig;    // sin() is overriden