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
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 reply 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
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