This patch is rather questionable, and thus I did not commit it directly. However, it illustrates a point I wanted to make.
As mentioned in my recent PARROT QUESTIONS email, a lot of the clutter in the PMC aggregates can be removed with the use of redirecting functions. The below patch reduces the resulting array.c from 40K to 20K, and the ..obj file from 25K to 33K (not that much). It introduces another layer of recursion into the code, while at the same time eliminating lots of duplicate code. If we disallow subclassing of the PMC, a lot of the vtable redirects in this code could be replaced with straight function calls (and those function calls could subsequently be inlined within the same .c file). After doing this, I wonder if it's not useful to allow an aggregate PMC to declare its inner type (in this case, PMC). The pmc2c.pl would then generate stub functions which converted from that base type to each of the requested types. This would allow PerlIntArraty to be a base of INT, yet perform auto-conversions to num, string, pmc, etc in the generated code. Is the patch here too recursive to be efficient, despite the reduction in actual code? Should all SELF->vtable methods on *.pmc files be made to call the appropriate function directly, and assume no subclassing? Another possibility is to regenerate the functions for the subclasses, so that parent inlinings of SELF->vtable->get_pmc_keyed will not interfere with a child's redefinition of their own get_pmc_keyed ? Thoughts, comments? Mike Lambert
