Thread overview
Dangerous Effects of Import within Class Body
Jun 11, 2004
John Reimer
Jun 11, 2004
Mike Swieton
Jun 13, 2004
John Reimer
Jun 11, 2004
Ant
Jun 13, 2004
John Reimer
June 11, 2004
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


June 11, 2004
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

June 11, 2004
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

June 13, 2004
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
June 13, 2004
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