#528: Clone and Modify in DynPMC VTABLE Initialization
-----------------------+----------------------------------------------------
Reporter: chromatic | Owner: chromatic
Type: roadmap | Status: assigned
Priority: normal | Milestone: 1.2
Component: none | Version:
Severity: medium | Keywords:
Lang: | Patch:
Platform: all |
-----------------------+----------------------------------------------------
Comment(by bacek):
Replying to [comment:2 cotto]:
> Replying to [ticket:528 chromatic]:
>
> > We need a way to map the appropriate slot in the vtable array for each
overridden entry. That's easy. We need a way for a dynpmc to access and
clone its parent's vtable. That's a little bit more work, if only because
we have to do this in generated code, and it's a divergence between how
dynpmcs initialize their vtables and how built-in PMCs initialize their
vtables.
>
> Why does there need to be a divergence? It sounds like this approach
would work just fine for built-in PMCs too, if perhaps with a slightly
higher runtime cost.
Ok. There is suggestion:
1. Split class_init into 3 functions: get_vtable , build_vtable and
init_mro.
2. build_vtable for all classes except "default" will be something like:
{{{
build_vtable(VTABLE * table) {
table[n] = Parrot_derived_foo;
table[k] = Parrot_derived_bar;
return table;
}
}}}
3. get_vtable will be
{{{
VTABLE * get_vtable() {
return
Derived_build_vtable(Parent1_build_vtable(Parent2_build_vtable(Default_build_vtable())));
}
}}}
4. setup_mro is "second pass" from current class_init.
With this approach we have to export maximum 2 functions from PMC. DynPMCs
will not be different from CorePMCs and use same approach.
--
Bacek
--
Ticket URL: <https://trac.parrot.org/parrot/ticket/528#comment:3>
Parrot <https://trac.parrot.org/parrot/>
Parrot Development
_______________________________________________
parrot-tickets mailing list
[email protected]
http://lists.parrot.org/mailman/listinfo/parrot-tickets
