[Python-Dev] type categories

[Greg Ewing]

David Abrahams <dave@boost-consulting.com>:

> I think it's unnatural to try to tie MULTImethod implementations to a
> single class.

I'm not sure what you mean by that. What I was talking about wouldn't
be tied to a single class. Any given method implementation would have
to reside in some class, but the dispatch mechanism would be
symmetrical with respect to all its arguments.

> When you try to generalize that arrangement to two arguments, you
> end up with something like the __add__/__radd__ system, and
> generalizing it to three arguments is next to impossible.

But it's exactly the same problem as implementing a generic function
dispatch mechanism. If you can solve one, you can solve the other.

I'm talking about replacing

  f(a, b, c)

where f is a generic function, with

  (a, b, c).f

(not necessarily that syntax, but that's more or less what it would
mean.) The dispatch mechanism -- whatever it is -- is the same,
but the generic function entity itself doesn't exist.

> Where to supply multimethods that work for types defined in
> different modules/packages is an open question, but it's a question
> that applies to both the class-scope and module-scope approaches

The class-scope approach would be saying effectively that
you're not allowed to have a method that doesn't belong in 
any class -- you have to pick a class and put it there.

That doesn't solve the problem, I know, but at least it
would be explicit about not solving it!

Greg Ewing, Computer Science Dept, +--------------------------------------+
University of Canterbury,	   | A citizen of NewZealandCorp, a	  |
Christchurch, New Zealand	   | wholly-owned subsidiary of USA Inc.  |
greg@cosc.canterbury.ac.nz	   +--------------------------------------+