I did a search on this forum for function overloading and for HiddenFunc and I didn't find anything, so I thought I would pose the question: is everyone generally agreed that the way function overloading works in 2.0 is a good idea?

I think anything that can cause runtime errors is generally something to be avoided, and reading about how HiddenFuncErrors can be raised threw up red flags for me as a bad thing. I can understand wanting to simpify things over C++, but not being able to access publicly declared super class member functions, not for technical reasons, but because of language design, and even worse, not revealing the errors until runtime, seems to me like something that will cause more problems in the long run than anything else. Today I finally got gtkD to compile and run successfully on the dmd 2.008 compiler, and much time was spent figuring out how to get a debugger working so I could get a stack trace to track down a HiddenFuncError in a very long class hierarchy so I could put in the correct alias declaration in the right class. This kind of problem certainly doesn't exist in Java and C# as far as I'm aware.

So basically I just wanted to learn more about the justifications for this design and how likely this feature will become permanent.

Sean Reque wrote:
> I did a search on this forum for function overloading and for HiddenFunc and I didn't find anything, so I thought I would pose the question: is everyone generally agreed that the way function overloading works in 2.0 is a good idea? 
> 
> I think anything that can cause runtime errors is generally something to be avoided, and reading about how HiddenFuncErrors can be raised threw up red flags for me as a bad thing. I can understand wanting to simpify things over C++, but not being able to access publicly declared super class member functions, not for technical reasons, but because of language design, and even worse, not revealing the errors until runtime, seems to me like something that will cause more problems in the long run than anything else. Today I finally got gtkD to compile and run successfully on the dmd 2.008 compiler, and much time was spent figuring out how to get a debugger working so I could get a stack trace to track down a HiddenFuncError in a very long class hierarchy so I could put in the correct alias declaration in the right class. This kind of problem certainly doesn't exist in Java and C# as far as I'm aware.

Do you mean function overloading or overriding?


Sean

Sean Kelly wrote:
> Sean Reque wrote:
>> I did a search on this forum for function overloading and for
>> HiddenFunc and I didn't find anything, so I thought I would pose the
>> question: is everyone generally agreed that the way function
>> overloading works in 2.0 is a good idea?
>> I think anything that can cause runtime errors is generally something
>> to be avoided, and reading about how HiddenFuncErrors can be raised
>> threw up red flags for me as a bad thing. I can understand wanting to
>> simpify things over C++, but not being able to access publicly
>> declared super class member functions, not for technical reasons, but
>> because of language design, and even worse, not revealing the errors
>> until runtime, seems to me like something that will cause more
>> problems in the long run than anything else. Today I finally got gtkD
>> to compile and run successfully on the dmd 2.008 compiler, and much
>> time was spent figuring out how to get a debugger working so I could
>> get a stack trace to track down a HiddenFuncError in a very long class
>> hierarchy so I could put in the correct alias declaration in the right
>> class. This kind of problem certainly doesn't exist in Java and C# as
>> far as I'm aware.
> 
> Do you mean function overloading or overriding?
> 
> 
> Sean

HiddenFuncError is cause by overriding overloaded functions so I would say both.

Sean Kelly Wrote:

> 
> Do you mean function overloading or overriding?
> 
> 
> Sean
I probably don't have the terminology right. Maybe the term is 'overload resolution'?  Robert described it right, I think. It occurs when you define a function of the same name as one or more functions in a superclass, which effectively shadows the super class function(s). If an object of the class is then up-casted to the super class with a shadowed function and that function is then called, a runtime exception is thrown.

Sean Reque wrote:
> Sean Kelly Wrote:
> 
>> Do you mean function overloading or overriding?
>>
>>
>> Sean
> I probably don't have the terminology right. Maybe the term is 'overload resolution'?  Robert described it right, I think. It occurs when you define a function of the same name as one or more functions in a superclass, which effectively shadows the super class function(s). If an object of the class is then up-casted to the super class with a shadowed function and that function is then called, a runtime exception is thrown.

Oh right, I'd completely forgotten this feature :-)  The discussion took place in this forum a few months ago under the subject "Overloading/Inheritance issue."  Here is a link to the first post:

http://www.digitalmars.com/pnews/read.php?server=news.digitalmars.com&group=digitalmars.D&artnum=56295


Sean

Thanks for the links! I was able to find through it two very long discussions on this issue. One point that was brought up is that the reason D implements overload resolution the way it currently does is because c++ did it the same way for 20 years and no one complained. Well, a lot of post were made about different aspects of the issue, so I want to just focus on the area I have the biggest problem with. I didn't read EVERY post, but I hope this is a newer way of looking at it. The following C++ program compiles fine:

#include <stdio.h>
class A {
	public:
	void print(int i) {
		printf("you gave me integer %d\n", i);
	}
};

class B : public A {
	public:
	void print(char c) {
		printf("you gave me character %c\n", c);
	}
};

void overload_res_test(A& a) {
	a.print(1);
}

int main() {
	B b;
	overload_res_test(b);
	return 0;
}

The following --equivalent-- D program crashes with a runtime exception that can  be debugged as far as I know with a debugger:

class A {
	public:
	void print(int i) {
		printf("you gave me integer %d\n", i);
	}
}

class B : A {
	public:
	void print(char c) {
		printf("you gave me character %c\n", c);
	}
}

void overload_res_test(A a) {
	a.print(1);
}

void main() {
	scope B b = new B();
	overload_res_test(b);

}

Like I said in my first post, I had to spend a long time getting a debugger to work when I tried compiling a hello world app with gtkD and I got a hidden function error. The shadowed method declaration was about 7 classes up the hierarchy, while the actual function that did the shadowing was about 3 or 4 up the hierarchy. The worst part about this is that the error is only revealed at runtime and only if the function is called under certain conditions. For a strongly-typed compiled language, in my opinion this is disastrous, and it's not what either C++ or Java does.

Sean Reque Wrote:

> The following C++ program compiles fine:
Oops! I meant to say it compiles and runs fine.

> The following --equivalent-- D program crashes with a runtime exception that can  be debugged as far as I know with a debugger:

I meant to say here that as far as I know this error can ONLY be debugged reasonably  with a debugger.

The final thing I had to note was that I recompiled the D program, declaring the functions as final, and it actually ran successfully. I recompiled the c++ program with the functions declared as virtual and it still ran fine. So the c++ function works for both virtual and static functions, while the D program works with static functions and crashes at runtime with virtual functions.

Sean Reque wrote

> The following --equivalent-- D program crashes with a runtime exception

No crash on my machine XP32, dmd 1.029.

-manfred

Manfred Nowak Wrote:

> Sean Reque wrote
> 
> > The following --equivalent-- D program crashes with a runtime exception
> 
> No crash on my machine XP32, dmd 1.029.
> 
> -manfred

I'm using D 2.009, and the crashing behavior is part of the 2.0 spec. That's one reason why I was posting, to find out if this behavior is already permanently in the language or still in alpha.

Sean Reque wrote:
> Thanks for the links! I was able to find through it two very long discussions on this issue. One point that was brought up is that the reason D implements overload resolution the way it currently does is because c++ did it the same way for 20 years and no one complained. Well, a lot of post were made about different aspects of the issue, so I want to just focus on the area I have the biggest problem with. I didn't read EVERY post, but I hope this is a newer way of looking at it.

Here are some of the posts that I was thinking of in particular:

http://www.digitalmars.com/pnews/read.php?server=news.digitalmars.com&group=digitalmars.D&artnum=56391
http://www.digitalmars.com/pnews/read.php?server=news.digitalmars.com&group=digitalmars.D&artnum=56414
http://www.digitalmars.com/pnews/read.php?server=news.digitalmars.com&group=digitalmars.D&artnum=56418

The different overload resolution schemes between C++ and D may be a factor as well.


Sean