Polymorphism problem w/local functions?

[Jonathan M Davis]

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