www.digitalmars.com         C & C++   DMDScript  

digitalmars.D.learn - Polymorphism problem w/local functions?

reply Magnus Lie Hetland <magnus hetland.org> writes:
Is it intended that local functions can't be polymorphic?

Example:

void foo(int x) {}
void foo(string x) {}

void bar() {
    void foo(int x) {}
    void foo(string x) {}
}

void main() {
}

The error (at line 6) is "declaration foo is already defined".

The code compiles if you comment out at least one of the local 
functions (but not if you, for example, comment out the global ones, of 
course).

Is this a bug, or am I just missing the reasoning behind it? Any 
workarounds? (I'm still at 2.052, so maybe this works in the new 
version?)

-- 
Magnus Lie Hetland
http://hetland.org
Jul 18 2011
next sibling parent reply Jonathan M Davis <jmdavisProg gmx.com> writes:
On Monday 18 July 2011 14:11:29 Magnus Lie Hetland wrote:
 Is it intended that local functions can't be polymorphic?
 
 Example:
 
 void foo(int x) {}
 void foo(string x) {}
 
 void bar() {
     void foo(int x) {}
     void foo(string x) {}
 }
 
 void main() {
 }
 
 The error (at line 6) is "declaration foo is already defined".
 
 The code compiles if you comment out at least one of the local
 functions (but not if you, for example, comment out the global ones, of
 course).
 
 Is this a bug, or am I just missing the reasoning behind it? Any
 workarounds? (I'm still at 2.052, so maybe this works in the new
 version?)

Well, technically-speaking, that's not really polymorphism, since the choice of function is decided at compile time (polymorphism would be dealing with overridden functions than overloaded ones), but I suppose that that's not really here nor there. In any case, no you can't overload nested functions. You've never been able to, and you still can't do it. I don't know _why_ such a restriction exists, but it does. Feel free to open up an enhancement request for it. I don't know that it'll do much good, but maybe you'll luck out. Not knowing why the restriction exists in the first place, I don't know what the chances are of that restriction being removed. For all I know, it's an Walter's TODO list. - Jonathan M Davis
Jul 18 2011
parent Magnus Lie Hetland <magnus hetland.org> writes:
On 2011-07-18 18:10:47 +0200, Jonathan M Davis said:

 Well, technically-speaking, that's not really polymorphism, since the choice
 of function is decided at compile time (polymorphism would be dealing with
 overridden functions than overloaded ones),

Right ... thought static overloading was considered a form of polymorphism as well. Aanyway... :D
 but I suppose that that's not really here nor there.

Right :)
 In any case, no you can't overload nested functions. You've never been able
 to, and you still can't do it. I don't know _why_ such a restriction exists,
 but it does. Feel free to open up an enhancement request for it. I don't know
 that it'll do much good, but maybe you'll luck out. Not knowing why the
 restriction exists in the first place, I don't know what the chances are of
 that restriction being removed. For all I know, it's an Walter's TODO list.

I see. Not really critical. As I've been thinking about the problem I was working on, I guess dynamic (i.e., "real") polymorphism is what I need anyway; I guess the (only?) way to do that would be to have a method on the objects in question. (Right...? There are no other dynamic dispatch mechanisms that I'm forgetting, other than type-based switch statements?) Thanks, - M -- Magnus Lie Hetland http://hetland.org
Jul 20 2011
prev sibling parent Jonathan M Davis <jmdavisProg gmx.com> writes:
On Wednesday 20 July 2011 12:32:50 Magnus Lie Hetland wrote:
 On 2011-07-18 18:10:47 +0200, Jonathan M Davis said:
 Well, technically-speaking, that's not really polymorphism, since the
 choice of function is decided at compile time (polymorphism would be
 dealing with overridden functions than overloaded ones),

Right ... thought static overloading was considered a form of polymorphism as well. Aanyway... :D
 but I suppose that that's not really here nor there.

Right :)
 In any case, no you can't overload nested functions. You've never been
 able to, and you still can't do it. I don't know _why_ such a
 restriction exists, but it does. Feel free to open up an enhancement
 request for it. I don't know that it'll do much good, but maybe you'll
 luck out. Not knowing why the restriction exists in the first place, I
 don't know what the chances are of that restriction being removed. For
 all I know, it's an Walter's TODO list.

I see. Not really critical. As I've been thinking about the problem I was working on, I guess dynamic (i.e., "real") polymorphism is what I need anyway; I guess the (only?) way to do that would be to have a method on the objects in question. (Right...? There are no other dynamic dispatch mechanisms that I'm forgetting, other than type-based switch statements?)

Well, if you're trying to have a function which changes behavior depending on one of its arguments, then you're either going to have it be a member function of a class where it changes behavior depending on the class itself, or you're going to have an overloaded function - which may very well be a template. Function overloads (templated or otherwise) are determined statically, whereas member functions of classes are determined dynamically (unless the compiler is able to determine at compile time that there's only one class that it could be, in which case the choice is probably made at compile time and the function isn't virtual). So, if you really want the function to be chosen at runtime, it's going to have to be using overidden member functions. You can, of course, change behavior of a function at runtime based on the value of its arguments (e.g. by using type-based switch statements), but that's not selecting the function dynamically. You could also have functions or delegates which you passed around. But those would be chosen dynamically based on arguments or anything like that. They'd just be whatever you set them to, which would require some sort of logic within the functions using them to select which function or delegate to pass around or use or whatnot. So really, if you functions to be chosen dynamically based on arguments, then you're going to have to use classes with overidden functions. - Jonathan M Davis
Jul 20 2011