[PEAK] Regular functions vs generic functions

[David Gowers]

Hi Aaron,

On Fri, Feb 15, 2008 at 2:44 PM, Aaron Lebo <aaron.m.lebo at gmail.com> wrote:
> There's a pretty major and obvious distinction between regular functions and
> generic functions in any language that supports them. Functions are
> relatively simple and easy to use, but functions are also somewhat limited.
> If I define a function named print, and I want it to support a new bit of
> data, I have to edit the source of the function itself. If I have a generic
> function print, adding new functionality is simple and seamless. I don't
> actually have to change existing code. That's the point of generic functions
> of course. :)
>
> Anyway, I'm wondering more about this distinction and it seems that any time
> you use a regular function, you've already set limitations on yourself. They
> simply aren't as extensible. I am interested if you could get by using only
> generic functions, or if you'd run into performance issues or other
> limitations that you wouldn't have in using both regular and generic
> functions (PEAK-Rules)?
>
> Is it feasible (or even something you'd want to do) to only use generic
> functions? I also noticed this line in the readme, which seemed related to
> my current question. "These decorators also all work with existing
> functions; you do not have to predeclare a function generic in order to use
> it." What does that mean in practice?
It means, there is not such a thing as a generic kind of function; The
way things work is that the bytecode of the function is modified. The
overhead in using generic functions, is AFAIK only this:
The normal overhead incurred by checking the conditions (eg, is
parameter 'color' a tuple, or is it an int?).
So if you manually expanded the function, it would run barely faster
(or possibly slower.).

Under simplegeneric, there is more of an overhead, since there is the
additional cost of function calls IIRC.

Hope that helps,
David