The current delegation internals are not likely a good match for languages like Python or Ruby. I see such languages as implementing their own semantics for classes, and Parrot limiting its knowledge to methods like findmeth and invoke.
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?
All *external* names should be looked up using find_method.
All names needed by the Parrot runtime need to be orthogonal to the set of names available for use by languages. Ideally this would be by virtue of using a separate mechanism (e.g., VTABLES), but acceptably it could be done by naming convention (leading double underscores with no trailing double underscores).
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.
The second dispatch may be spelled "string_str_index", in which case the loader does all the necessary fixup. The second dispatch may be spelled "VTABLE_get_pmc_keyed" in which case we are looking at a couple of pointer hops and some integer arithmetic. The second dispatch may be spelled "SUPER()" and use some combination of these. Or it could be using find_method, or perhaps even another technique entirely.
But in all cases, we are looking at two different things.
= = =
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.
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.
... What do we benefit from the premature pessimisation of mapping this to a string?
Well, method names happen to be strings ;)
Using the table below, at the moment, there are exactly zero strings materialized and/or compared against during the execution of vtable/PMC methods.
I don't get that sentence.
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.
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.
= = =
I plan to spend the next day or so looking into catching named exceptions, after which point I plan to implement Python classes on Parrot. I do not anticipate using globals or ParrotObject or ParrotClass in that implementation. I expect that there will be tests that replace methods, and I hope that optimizations that attempt to cache the results of find_method don't prevent these updates from being seen.
I don't believe that it is a good idea for Python specific functionallity to be present in the core Parrot runtime. For that reason, I will implement this functionality inside dynclasses. If the runtime provides reasonable hooks for the functionally, I will use them. If not, I will temporarily clone and modify what I need, with the intent of getting it working first, and then refactoring the appropriate parts back into the Parrot runtime, this time with the necessary intercept points. In rare cases - when I feel confident enough - I may modify the Parrot runtime to provide the hooks I need.
And all of this will be backed by test cases so that such refactoring can be done confidently and correctly.
If anybody has any issues with this plan, please let me know now.
- Sam Ruby
