Re: Overloading function calls

Marc Wachowitz (mw@ipx2.rz.uni-mannheim.de)
5 Jun 1994 12:08:34 GMT

Tim wrote:
> The way I picture it:
[... correct description deleted for brevity]
> + How coercions-- when desired --work under this approach isn't clear to
> me. E.g., I wanted to write the Date class so that
>
> "5 Jun 1994" - Date
>
> would work in the obvious way.

If _no_ applicable direct method is found (but _not_ in the case of several
methods with the same degree of specialization - see my remarks why I don't
like too much ambiguity to be solved by default in the previous article), a
coercion multi-method for the argument pair is searched for, and the result
is tried again. If there is still no operator method, further coercion will
be applied while there are appropriate functions. Cycles will be detected.

In this case, register methods for (type(""), Date) and (Date, type("")). A
shorter way to register a coercion for both the given order and the reverse
order may of course be provided.

> But moving the implementation of class methods out of
> the class body is unattractive (e.g., where does one look to find the
> implementation of "typeA - typeB"?

IMO that's just a question of the appropriate development system. Bad style
can't be completely prevented anyway, and if someone isn't able to choose a
reasonable location for such registration - documenting non-obvious cases -
I guess looking for multi-methods would be the smallest problem when you're
maintaining the code.

> presumably, if adopted, the approach
> shouldn't be limited to special class methods -- right?

The facility should of course be used for all methods, though it would only
be applied automagically for the builtin operators. Other functions/methods
would have to make an explicit request for it, like invoke_multi_method_for
(args ...), though of course with a shorter name.

> how much slower (or faster?) it would run than the current scheme,

That would be a tradeoff between speed and specialization (having a special
registration for the expected signatures would always be possible).

> how much existing code it would break

Since multi-methods are just a shorter form of writing <if>s, we could very
likely define it in whatever way we like, choosing where we want a new kind
of functionality and where not.

> wondering-mostly-how-ordinary-overloaded-functions-got-the-word-
> "methods"-applied-to-them<wink>-ly y'rs - tim

They are just extended methods, where there's more than one "receiver" (aka
"self") argument. Maybe have a look at Chambers' paper, on "Object-Oriented
Multi-Methods in Cecil".

------------------------------------------------------------------------------
* wonder everyday * nothing in particular * all is special *
Marc Wachowitz <mw@ipx2.rz.uni-mannheim.de>