Re: Polymorphism problem w/local functions?

2011-07-20 Thread Magnus Lie Hetland 

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

Re: Polymorphism problem w/local functions?

2011-07-20 Thread 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

Re: Polymorphism problem w/local functions?

2011-07-18 Thread Jonathan M Davis 
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