www.digitalmars.com         C & C++   DMDScript  

D - modules again

reply "Pavel Minayev" <evilone omen.ru> writes:
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?
Nov 20 2001
parent reply "Walter" <walter digitalmars.com> writes:
"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).
Nov 20 2001
next sibling parent "Pavel Minayev" <evilone omen.ru> writes:
"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.
Nov 20 2001
prev sibling parent reply Russell Borogove <kaleja estarcion.com> writes:
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
Nov 20 2001
parent reply a <a b.c> writes:
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
Nov 23 2001
parent "Pavel Minayev" <evilone omen.ru> writes:
"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
Nov 23 2001