[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: overloading functions (Was: Indirect Addressing Question)

From: Jonathan King
Subject: Re: overloading functions (Was: Indirect Addressing Question)
Date: Fri, 16 Nov 2001 11:46:42 -0600 (CST)

On Fri, 16 Nov 2001, John W. Eaton wrote:

> On 16-Nov-2001, Paul Kienzle <address@hidden> wrote:
> | Matlab decides what function to call based on the type of the
> | first argument, which can be done reasonably cheaply and
> | handles the majority of the cases.
> This kind of design decision is what bugs me about Matlab, I think.
> "It will work most of the time.  Users won't be too bothered when it
> fails.  After all, we don't expect anyone to actually notice the
> inconsistency because it will come up so infrequently."
> Ugh.

I agree with you in principle, but dispatch on only the type of the first
argument is pretty common (this isn't just a Matlab thing), and it works
well in a rather large majority of cases (in my experience).  Moreover, it
gets around the surprisingly common problem of people not really
understanding the ins and outs of the dispatch algorithm in the system
they're using, or all of the potential matches available in their system.
My hunch is that this is particularly problematic when you're talking
about typing stuff in at the command-line.

> | You could extend this so that if any of the arguments were of
> | a user defined type, then check for a type specific function, but
> | that won't scale well if there are a lot of user defined types
> | around.
> It would be fine and could probably even be relatively efficient if
> functions had signatures (by that I mean a corresponding declaration
> of the types and number of parameters they can handle; may be more
> than one signature for a given function definition) and all functions
> had to be loaded before they could be considered.  But that's not very
> Matlab-like.  Function definitions would have to change because there
> is no way to determine what types of arguments a function can accept
> just by looking at it, and there could be no more implicit
> autoloading.

Actually, couldn't you just do a complete type class and type
inference system like Haskell? (Ducking, and successively avoiding
thrown objects. :-))


Octave is freely available under the terms of the GNU GPL.

Octave's home on the web:
How to fund new projects:
Subscription information:

reply via email to

[Prev in Thread] Current Thread [Next in Thread]