From octave-maintainers-request at bevo dot che dot wisc dot edu Thu Jan  8 12:11:19 2004
Subject: Re: polymorphism in functions
From: taltman at lbl dot gov
To: "Pascal A. Dupuis" <Pascal dot Dupuis at esat dot kuleuven dot ac dot be>
cc: octave-maintainers at bevo dot che dot wisc dot edu
Date: Thu, 8 Jan 2004 18:11:07 +0000 (UTC)

On Jan 8, 2004 at 3:47am, Pascal A. Dupuis wrote:

Pascal >Hello,
Pascal >
Pascal >I'm writing a function to test if data can be described by some
Pascal >pdf. Similar to hist(), data are collected in bins, and expected and
Pascal >observed occurences are compared for the bins.
Pascal >
Pascal >But I rapidly found myself in need of some flexibility: I can wish to
Pascal >pass mu and sigma for a normal distribution, or a vector with
Pascal >threshold values for the bins, or a set of threshold and expected
Pascal >number of occurences to avoid recalculating the latter each time, or ...

Why don't you just use a message-passing style? Write three different
functions, and then a master-function which calls any of those three
depending on what message is passed to it. See "Structure and
Interpretation of Computer Programs" for more.

Pascal >Implementing polymorphism requires to test the number and types of
Pascal >input arguments, but this becomes rapidly complicated to get things
Pascal >working right.

Sorry. No matter how you slice it, you will never be able to "program
your way" out of testing inputs. Even in the most
strongly/strictly-typed languages, you have to ensure that the
variable is within the allowed range of operation for your function.

Pascal >One possible solution is to use a formalism of named arguments, like
Pascal >in R: 

[snip]

Pascal >So you get an idea of the flexibility. At the program level, things
Pascal >are rather simple:

Yes, and this would be rather simple to program in Octave as-is. Just
use some 'varargin' & some if-elseif-else cascades, and you're there.

[snip]

Pascal >Advantages:
Pascal >-more flexibility in the way the function works;

       Unjustified. How is it more flexible than the "'varargin' with
       message-passing-style" approach?

Pascal >-ability to add supplemental variables arguments without breaking
Pascal >compatibility with previous scripts

       With 'varargin', you can extend scripts without breaking old code.

Pascal >-safer to program; doesn't require a lot of (dynamic) tests to decide how to
Pascal >take the arguments into account.

       How is it safer? No computer language can completely solve the
       problem of checking inputs.

Pascal >Problems:
Pascal >-code a bit bigger
Pascal >-each function invocation will be translated into an initial code
Pascal >performing the variable setup, followed by a call to the function
Pascal >core.

And if people complained about slow-function calls before, now every
function call will have an increased latency.

My final thoughts: 'varargin' and 'varargout' can accomplish a lot of
this magic as-is.

Just my $0.02,

~Tomer