At 03:44 PM 12/30/2001 +0000, Alex Gough wrote:
>I tried to do some of this yesterday and got myself into a massive
>muddle, in trying to rescue myself from this muddle I took a wrong
>turning and found myself in a dark and dismal can of worms. Then I
>ate the worms, because I was hungry, not because no one liked me.
>
>Anyway, getting back to the point... I think we need to modify how we
>do vtables at the moment, consider the following:
>
>a) div P0, 1, P1
>b) div P0, P1, P2
>
>(a) will call P1->divide_native(P1, 1, P0) but what will div P0, P1, 1 call?
> (Or vice versa?)
In example a), the 1 has to be a PMC constant. So it calls the PerlInt
division vtable entry.
>(b) will call P1->divide(P1, P2, P0), but what happens if P1 is a
>PerlInt and P2 is a PerlRef (say) which is blessed to overload '/' (or
>even a PerlBigInt, which essentially overloads '/') , somehow the
>PerlInt is going to have to know what to do.
Yup. The division op checks the type of P2 to figure out which of P1's
division entries to call. If P2 isn't a known type (i.e. int, float, or
bignum) then it calls P1's "divide-with-your-second-parameter-an-object".
That entry *may* have a multimethod behind it, in which case Parrot would
look up the appropriate entry and call it. On the other hand there's no
requirement for that to be the case--P1's division-with-funky-arg entry may
just unconditionally call get_int on P2 and do the division it feels like
doing.
>So I think we'll need to make the following changes:
[Cogent argument snipped]
Good ideas, but too much work. The LHS will govern what happens, otherwise
you get into the "what if *both* sides are marked as special--then what?"
problem. Punting is OK.
Though I can see some other ways around it. I'll think on it a bit.
Dan
--------------------------------------"it's like this"-------------------
Dan Sugalski even samurai
[EMAIL PROTECTED] have teddy bears and even
teddy bears get drunk
