The abstract for mmtc.ps starts:
> Two major obstacles preventing the wider acceptance of multi-methods
> are concerns over the lack of encapsulation and modularity and the lack
> of static typechecking in existing multi-method-based languages.
The first point is the one I picked up on, and is echoed in the abstract
> ... existing languages with multiple dispatching do not encourage the
> data-abstraction-oriented programming style that is encouraged by
> traditional single-dispatching languages; instead existing multiple-
> dispatching languages tend to foster a function-oriented programming
> style organized around generic functions. ...
So I assume the papers will address my vague fears about those points in
The second point may be worse: I assume that "concern ... for lack of
static typechecking" is a combination of "safety" worries and an academic
euphemism for "runs like a pig" <wink>. I did note that the body of
profiles.ps mentions that profile-feedback-based compiler optimization of
polymorphic dispatch sped up Cecil programs by a _factor_ of 2 to 4.
Where on the spectrum from "wow! they sure did a good job on the
optimizer!" to "wow! naive runtime multi-method dispatch is incredibly
slow!" the truth lies is hard to say.
Also hard to say how well a different worldview _could_ fit into Python;
or how well Python's would fit into Cecil's <wink>. Whatever, I'll delay
speculation until reading the stuff.
Quick random responses:
> > > [marc w]
> > > Adding some support for testing whether some class is a (direct or
> > > indirect) subclass of another probably wouldn't hurt.
> > [tim, sez you can write this in python now]
> [marc w]
> For a basic dynamic dispatching system (like for arithmetic), doing such
> a lookup completely in C would probably be a big performance advantage.
Yes, but Python as it is doesn't go thru the general class mechanisms to
figure out dispatching for built-in types, and neither can built-in types
be used as base classes in Python. So Guido would have to change the
language in deep ways before inheritance testing became a performance
bottleneck for most people.
> > OTOH, it's unclear that it's a Good Thing to separate the implementation
> > from the class body.
> IMO, that's a question of having a good development system. It's already
> possible to add features to an object dynamically, and without expecting
> a reasonable placement of statements, functions, methods and classes, an
> OO software will always be a mess for maintainers.
Agree it's a question of adhering to good style, but as in the recent
Syntax Wars, it's always nice if an Objectively Correct style both exists
& is enforced by the language. Think it is worth _something_ that special
methods have to follow certain rules today; everything's a tradeoff.
> > [sketches an ambiguous multi-method scenario]
> Particularly for languages without full static typing, I would signal an
> exception in such cases of ambiguity (at call time).
I would too, but that's part of my "speed" concern: in a language with
_no_ static typing, and no optimizer on the horizon, dispatches requiring
complex searches are going to be s-l-o-w. Single-dispatch is already
very slow in Python when it needs to search up an inheritance chain;
crawling up multiple chains thru a general DAG at runtime is almost
scary. But I can't yet picture exactly how this works in all cases, so
can't rule out the possibility of efficient runtime support a priori.
Ditto wrt your later sketch of how coercions might work out.
> > Marc, you're not a heretic!
> Oh, then it seems I'll still have to work a bit on that - wait until you
> see my further suggestions to transform Python into a combination of Ada
> and Common Lisp ;-)
X3J3 has been charged with adding object-oriented features to Fortran-90's
successor too, and I'd hate to see us miss a trick <wink>.
Speaking of which, I also picked up a copy of the CLOS Meta-Object
Protocol spec, and noted that it alone runs well over 100(!) pages.
To become a heretic requires a bold act directly opposing a central tenet
of The Doctrine: you'll never become a heretic by proposing 50,000 new
words' worth of downward-compatible doctrine. Python, like capitalism
and love, eventually co-opts all who seek to change it <grin>.
> [a cogent stab at sketching more-precise rules]
> If there is more than one method in the most specific set, the call cannot
> be resolved; raise an exception, too. One might think of some explicit way
> to react to such ambiguities on a per-class and/or per-method basis, but I
> wouldn't recommend a default handler for this case.
Another possibility (well, there are of course many, but I'm trying to
restrict it to cases that aren't obviously nuts ...) is that _all_ the
most-specific methods should be invoked. Doesn't CLOS do something akin
to that (with something like "call-next-method" used to invoke "the next"
matcher)? Whether or not CLOS does, it's an interesting possibility.
> ... Though it's easy to think of other schemes based on the remaining
> sets computed above, they will usually lead to ambiguities and/or
> unexpected behaviour.
OK, and I'll happily agree to consider just the obvious cases before
worrying about bizarre variations. Strike the preceding paragraph from
> [steve m]
> Of course, Guido already has a title: "Guido". If he ever hands it
> down to a successor, it will become a generic name, sort of like
Poor Guido -- his already _is_ a generic name! I've noticed too that I
use "Steve M" as a generic name for "someone who will do the sickest
thing possible with any proposed feature" <wink>, much as you use "Tim"
as a generic name for "obnoxious wet blanket who can't understand a word
anyone says" <grin>. We've all existed forever; we'll never die <smile>.
> BTW: Thanks, Marc, for directing the discussion AWAY from
> whitespace/block-delimiters syntax to something more interesting! ;-)
Isn't that odd? Mailing lists do tend to focus on one topic at a time,
but I thought the usenet group would tend more toward multiple active
threads than it has so far.
y'rs - tim
Tim Peters email@example.com
not speaking for Kendall Square Research Corp