>> 2.) Can you give an idea of what you think the macro-ized function should >> look like (an example would be great.)
>No, because then you'll go away and implement it, and I want to >encourage >some fresh blood to do that. :) Okey Dokey...I promise not to do it :) >Seriously, before I do that, I need to seriously think about what vtable >accessors ought to look like; > (pmc1->vtable[want_vtbl_add])(pmc1, pmc2, pmc3) >is going to scare people away quickly, and, while > PMC_ADD(pmc1, pmc2, pmc3) >s cute, (and allows us to autogenerate Parrot byte ops ;) Macro >Hell is something we want to avoid. Well, you currently have vtable as a struct so you would say pmc1->vtable->add( pmc1, pmc2, pmc3 ) which doesn't look that bad. Really, I would imagine all of this would be autogenerated by process_opfunc.pl so it doesn't matter what the longhand looks like. We can use PMC_ADD in basic_opcodes.ops just like we use INT_CONST or whatever and the macro is stripped out of the perl. Also, how will adds of different types be handled. In the above if pmc2 is an int and pmc3 is a float we're going to have to know that and do a switch or something to convert to/create the right type. Tanton
