On Saturday 06 October 2001 01:13 pm, Michael Maraist wrote:
> So would it be something like(ultimtaely put into a macro):
> AUTO_OP add_p_p_p {
> if (!P1)
> CREATE_PMC(P1);
> if (!P2 || !P3)
> throw exception; // however this is done in Parrot
> P2->vtable->add[P3->type]->(interp, P1, P2, P3); //in macro
> }
>
> In this way each vtable operation is really an array of handlers for
> each possible type of input.
Arghh, no. Surely you don't mean 'each possible' the way that I'm reading
'each possible'? [1]
>
> int_pmc_vtable = { ....., { pmc_vtable_add_int_int,
> pmc_vtable_add_int_float, pmc_vtable_add_int_string,
> pmc_vtable_add_int_iconst, pmc_vtable_add_int_fconst, ... }, ... };
And each and every class, object, and package that potentially creates
and/or modifes its vtable.
{snip}
>
>
> This assumes that a = b op c will be the same as a = b.op( c ), which
> I think is fair. Thus add_float_int produces a float while
> add_int_float produces an int. The compiler can worry about the order
> or the parameters.
add int_float should also produce a float. (Barring 'use integer', string
typing, or overloading.)
{snip}
>
> My question at this point is if the PMC's are polymorphic like Perl5
> or if there is an explicit type type. Polymorphics can make for vary
> large vtable sub-arrays. (int, int_float, int_float_string,
> int_string, etc).
Polymorphic plus, I believe.
[1] "And don't call me Shirley."
--
Bryan C. Warnock
[EMAIL PROTECTED]
