Sam Ruby <[EMAIL PROTECTED]> wrote: [ snipped - all ok }
> If I define an __add__ method with 16 arguments, Python will not throw > an exception. I didn't write that. I've said: *if* you call it via "a + b", Python throws an exception - that one I've shown. Anyway... > If this is done at runtime, the it need not be done at compile time. ... Yes. That's the overall conclusiom it seems. It can be done partially at compile time, and it isn't worth the effort to try it, because languages we are targeting are too dynamic. > However, it doesn't stop here. Just like methods can be added > dynamically by name at runtime, they can be accessed dynamically by > name. That means that all method lookups will need to be preceeded by a > hash lookup. An not just on Python objects, but *all* objects. ... preceeded by some kind of lookup, which is defined by "class->vtable->find_method()" of the responsible metaclass. Being it one or 100 hash lookups in properties, dicts, globals and what not. It doesn't matter. Dot. > That's why I object to characterizations like "dynamic dispatch is 30% > faster than...". What will ultimately result if it is mandated that all > languages adopt Perl6's semantics is that an ADDITIONAL dynamic dispatch > will be required to make non-Perl6 functions work. You are still not getting the principal of the scheme, IMHO. It has nothing to do with Perl6 or any other language, nor with Python. The original subject: "premature pessimization" strikes back :) Whe just do a dynamic lookup at runtime - that's all. The e.g. "add" opcode calls left->vtable->find_method(), and probably more if the return results inidicates MMD. Eventually one of the find_method calls returns a function that does implement the "__add" method for the involved types. Or a (possibly user provided) distance function decides, which function to call. It doesn't matter. Then the *runcore* calls the function and *caches* the function pointer. Next time the call is instantaneous, given that the language is able to call a cache invalidation function, if method lookup order (for that class) changes. The call to the invalidation function is possible, even for Python. *Iff* you can roll your own method dispatch, you eventually need to know, which method you call. That has to be defined. You can as well call a cache invalidation function, if something changes here (I hope) > PerlScalar's implementation of the add will know about how to implement > Perl 6's multi sub *infix. PyObject won't, but it will know about > Python's __meta__ and __init_class__. If even an "add" instruction doesn't work outside of one HLL, we can forget any interoperbility. "__meta__" and what not Python semantics can be added - or not :-) But let's first concentrate on the basics. > - Sam Ruby leo
