Re: Fwd: Re: Fwd: Considering adding a "dispatch" function for compile-time polymorphism

[Jordi Gutiérrez Hermoso]

On Mon, 2014-08-11 at 14:03 -0400, John W. Eaton wrote:
> I'm forwarding this to keep the discussion on the list.
> 
> jwe
> 
> -------- Original Message --------
> Subject:      Re: Fwd: Considering adding a "dispatch" function for
> compile-time polymorphism
> Date:         Sat, 9 Aug 2014 13:30:03 -0600
> From:         David Spies <address@hidden>
> To:   John W. Eaton <address@hidden>
[snip]
> Function overloading should be reserved for public/interface methods
> where it doesn't matter which one is called.
> 
> This is why I never write functions that behave like:
> 
> myFun(x) {
>     //Do some stuff
> }
> 
> myFun(y) {
>     myFun(y_to_x(y))
> }
> 
> Sure, it's legal, but depending on the circumstances, the compiler still
> might decide y_to_x(y) should be implicitly cast (or in this case,
> template-resolved) to a y and end up calling the second myFun (resulting
> in baseless recursion).
> 
> (What's fun about this bug in general is that if you compile and run it
> with O0, you get a stack-overflow, but with O3, it uses tail-call
> optimization to eliminate the recursive call and the program hangs instead)
> 
> The defensive driving practice is:
> 
> myFun(x) {
>     private_myFun(x)
> }
> 
> myFun(y) {
>     private_myFun(y_to_x(y))
> }
> 
> private_myFun(x) {
>     //Do some stuff
> }
> 
> This avoids giving the compiler an opportunity to misinterpret.

Sorry, my attention was just drawn to this segment. I don't understand
how could this possibly happen, nor why you wrote this particular
diatribe against function overloading. You seem to dislike function
overloading in general? 

Under what situation would Y_to_X give you back a Y and not an X? If
Y_to_X were templated, wouldn't you template it as convert_Y<T> and
call convert_Y<X>(y), that is, wouldn't you need an explicit template
parameter anyways? Templates in templated functions are not resolved
according to the function's expected return type.

As to the greater context of this...

I know you might feel like you're getting particular scrutiny over
your code, and you are. It's true that we get lazy over reviewing
other people's code, and a lot of bad code has gotten into Octave
because there was no review, but the people who did that usually had
their code reviewed in the beginning, and we just trusted them to do
the right thing later. In some cases we shouldn't have, so we're
trying to make sure that, well, you're a team player, you can take
criticism, and you can agree to make changes to your code.

What changes and concessions have you made to improve your code?

- Jordi