• "Pavel Minayev" <evilone omen.ru> Nov 20 2001
• "Walter" <walter digitalmars.com> Nov 20 2001
• "Pavel Minayev" <evilone omen.ru> Nov 20 2001
• Russell Borogove <kaleja estarcion.com> Nov 20 2001
• a <a b.c> Nov 23 2001
• "Pavel Minayev" <evilone omen.ru> Nov 23 2001

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