Sam Ruby <[EMAIL PROTECTED]> wrote:
> Leopold Toetsch wrote:
>> Another good reason to use pmc->vtable->fine_method in *all* lookups. So
>> the PMC has full control over the dispatch.
> How does one lookup the C<find_method> method? That will remain a
> VTABLE, entry right?
Yes of course.
> All *external* names should be looked up using find_method.
Yes. But what's an external name? What happens if a Perl6 guru installs
a global overloaded add function:
multi sub *infix:<+>(Int $l, Int $r) { ... }
for example to count all "add" operations or whatever. This can
currently be done with the C<mmdvtregister> opcode. But that installs only
one MMD function for one type pair. What if some classes inherit the
"__add" method from C<Int>. Or:
multi sub *infix:<+>(Any $l, Any $r) { ... }
which presumably would influence all Perl types.
Citing S06: "Operators are just subroutines with special names."
Doing the same overloading with prefix or postfix operators OTOH would
change vtable methods. That's currently not possible because the vtable
dispatch is static, except for objects where it's dynamic.
> We also need to be aware that in the general case, we are talking about
> two lookups. One to find the language specific wrapper. And one to
> find the common code which backs it.
Yes, but when the HLL method is found (e.g. PyStr.index) you just call
the implementation statically and adjust e.g. return values.
> The second dispatch may be spelled "string_str_index",
... the second dispatch is basically not dispatch, it's a function call.
> Why is this issue so important to me? I see a lot of things I like
> about Parrot, but at the moment, the notions that are baked into the
> core as to how classes should work is not one of them.
You can straightforwardly use Parrot's object system for attributes and
methods with all stuff known at compile time, AFAIK. You basically just
extend the find_method and get_attr_str vtables.
WRT find_method: S13 mentions multi subs per package or even lexically
scoped. So we'll probably have to extend the method lookup anyway.
> I see a change that went in today to invalidate a method cache if a
> store_global call is made. That presumes a lot about how find_method
> works internally. An assumption that will not be valid for a number of
> languages.
Well, the builtin method lookup system with the default find_method
implementation is using it. But the cache is fully transparent.
> VTABLE_xxx depends only on pointer arithmetic and dereferencing. Yes,
> 20% of the operations may need more, and that should be provided for,
> but if 80% of the calls can be done this way, the performance benefits
> are significant.
Please don't start arguing with estimated performance benefits. I've
already shown that we can do the current MMD operations 30% faster -
but with dynamic dispatch too.
We need at the opcode level a dynamic dispatch. Internally the vtable
call remains. I've written that already a few times.
> As you tirelessly point out, this is all internal. The way the ops are
> coded in the IMCC source need not change. However, prematurely mapping
> *all* method names to strings so that a second method dispatch can be
> done in 100% of the cases is a premature pessimization.
Well better schemes for method overloading (e.g. in Python metaclass)
are always welcome. I've proposed a scheme. And yes, it's an
implementation detail.
[ dynclasses ]
> If anybody has any issues with this plan, please let me know now.
Python specific stuff should of course move out from core. For the rest:
It depends. If you end with a duplicate of CPython's Objects directory
interoperbility will be difficult.
> - Sam Ruby
leo
