www.digitalmars.com         C & C++   DMDScript  

digitalmars.D.bugs - Dangerous Effects of Import within Class Body

reply John Reimer <jjreimer telus.net> writes:
The compiler spits out errors if I attempt this code:

//------------------------------------
class A {
        void close() { }
        void read(char[] t) { }
}

class B : A {
        private import std.c.linux.linux;  // imports linux C read() and close()
        
        this() { 
                read("a");    // ERROR: incorrect arguments
                close();  // ERROR: incorrect arguments
                }
}
        
int main (char[][] args) {
        B b = new B;
        b.read("a");   // ERROR: incorrect arguments
        b.close();     // ERROR: incorrect arguments
}
//---------------------------------------

Why is this so?  Apparently importing the linux C functions completely
overrides the class methods permanently!  Fully qualifying these functions
such as b.close() or b.read("a") within main produces the same error since
the compiler still trys to call the linux C close() and read().  Why would
C function imports override class methods?  Dmd doesn't even attempt any
reasonable method overloading in this situation.  The original class
methods are completely lost due to the import.

Using imports within the class body used to be an effective way to reduce
forward reference errors.  Obviously, though, moving an import inside the
class body produces a very serious side effect that effectively eliminates
useful programming techniques.

Is this problem going to be fixed?

Thanks,

John
Jun 10 2004
next sibling parent reply Mike Swieton <mike swieton.net> writes:
On Thu, 10 Jun 2004 22:02:42 -0700, John Reimer wrote:

 Why is this so?  Apparently importing the linux C functions completely
 overrides the class methods permanently!  Fully qualifying these functions


As I recall, import will import things into the current scope. I suspect it's
being imported as a static member of the surrounding class. Unusual,
definately. I'm wondering why it's not treated as an overload though - why
should it hide the original method?

Mike Swieton
__
We must respect the other fellow's religion, but only in the sense and to the
extent that we respect his theory that his wife is beautiful and his children
smart.
	- H. L. Mencken
Jun 10 2004
parent John Reimer <brk_6502 NOSP_AM.yahoo.com> writes:
Mike Swieton wrote:


 On Thu, 10 Jun 2004 22:02:42 -0700, John Reimer wrote:
 

Why is this so?  Apparently importing the linux C functions completely
overrides the class methods permanently!  Fully qualifying these functions


 
 
 As I recall, import will import things into the current scope. I suspect it's
 being imported as a static member of the surrounding class. Unusual,
 definately. I'm wondering why it's not treated as an overload though - why
 should it hide the original method?


That's my question also.  I believe it's important enough that it needs 
to be fixed.  Is there ANY way at all to even access the class methods 
in this situation?  I don't think so...

The way things are now, absolutely no code should import inside a class 
in any sizeable project.  The risk is too great that an invalid function 
will be called if the arguments happen to be the same (in that case the 
compiler won't catch it).  That would make for a ugly, hidden bug.

So import ends up losing a significant amount of usefulness...

Later,

John
Jun 13 2004
prev sibling parent reply Ant <duitoolkit yahoo.ca> writes:
On Thu, 10 Jun 2004 22:02:42 -0700, John Reimer wrote:


 
 Using imports within the class body used to be an effective way to reduce
 forward reference errors.  Obviously, though, moving an import inside the
 class body produces a very serious side effect that effectively eliminates
 useful programming techniques.
 
 Is this problem going to be fixed?
 


I doubt.
This started with 0.91.
DUI and leds don't compile since.
(no matter all the work arounds I could throw at it).

The forward reference problems are back.
the std. conflicts are back.

I believe all boils down to the private on import not being respected.
this allows us to use functions not imported on the module
and as Charles showed (probably over 6 months ago) this is cause of
lots of problems.

Walter is adding new features without fixing well documented errors,
I hope he knows what is doing. I like to fix my errors as soon as possible.

I'm waitting for 0.93 all development on DUI and leds is halted.

Ant
Jun 10 2004
parent John Reimer <brk_6502 NOSP_AM.yahoo.com> writes:
Ant wrote:


 I doubt.
 This started with 0.91.
 DUI and leds don't compile since.
 (no matter all the work arounds I could throw at it).


Ouch!


 The forward reference problems are back.
 the std. conflicts are back.


These issues may indicate bad news for further work on DWT also...


 I believe all boils down to the private on import not being respected.
 this allows us to use functions not imported on the module
 and as Charles showed (probably over 6 months ago) this is cause of
 lots of problems.
 
 Walter is adding new features without fixing well documented errors,
 I hope he knows what is doing. I like to fix my errors as soon as possible.


Agreed, I really think this one should be on his important list of 
things to fix!  New features are of little use in larger projects if 
basic bugs are preventing any further development.


 I'm waitting for 0.93 all development on DUI and leds is halted.
 
 Ant
 


Walter, fix, fix, fix!  (please)

-John
Jun 13 2004