[EMAIL PROTECTED] wrote:
> Dan, I don't immediately see how per object/class dispatch
> control helps to make multimethods pluggable.
The way to approach this problem is to profile
Class::MultiMethods and figure out (a) where the hot spots
are and (b) what core support would help eliminate those
hot spots.
The one thing I'm curious about is whether different syntactic
conventions affect the dispatcher or whether this is all just
sugar for a single dispatch. Perl 5 uses several different
sub call syntaxes:
$obj->method(...)
method $obj ...;
function($x, ...);
$obj->Scope::method(...)
Scope::method $obj ...;
Scope::function($x, ...);
Does the C style dispatch differently from the C++ style?
I'd expect indirect object syntax to dispatch like C++
syntax since indirect object syntax is just sugar. But is
it possible to tell the difference between C style and
indirect object style for functions of arity 1?
IMHO it would be very nice if everything was just sugar
for "function($x, ...)". It would be harder to define
the nearest multi-method, but at least we wouldn't
have to worry about different dispatchers kicking in when
we didn't expect them to.
> Is there a general mop for dispatch?
Some pointers to meta-object protocol would be nice, if
only to establish common terminology. Do we all agree with
RFC 92's terminology and references? I only know a bit
about CLOS and I'm afraid that I'm going to confuse generic
MOP concepts with the CLOS implementation.
I have a few questions about MOPs.
Is there a difference between a meta-object system and
a meta-object protocol? They seem like data-structure
vs. algorithm views of the same thing.
Dispatch is a small part of a MOP. Is there a difference
between attribute (slot) lookup and method lookup? Is
dispatch trivial once method lookup is defined?
Is it a requirement for a MOP to defined in the target
language, or can it exist outside the language? For
example, CLOS' MOP can be changed using Lisp. C++'s MOP,
if it has one, can't.
How much of the MOP do expose to Perl programs?
- Ken
