On Sun, 30 Dec 2001, Simon Cozens wrote:
>
> > An updated TODO list is needed. As is maybe a reminder on bugs.perl.org.
>
> The things that I want to happen for 0.0.4 are not sexy. They are
> definitely not cool things, so I don't exactly expect people to be
> jumping at the chance to do them. That's fine. However, what I really
> would like to see happening as well as all the cool things are:
I propose that we extend the value of cool to include useful things
that mean we can compile languages so that the really cool things
actually become useful rather than mere diversions.
> Support for hashes. (I think Jeff's nearly got this.)
> UTF support to become as well-implemented as the native stuff.
Yes please. Is there anything that we can steal from perl5 for this?
> Many more of the PMC methods implemented.
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?)
(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.
So I think we'll need to make the following changes:
* PMCs will need a flag that tells other PMCs that they care about what
gets done to them, and that calling value->get_number Just Won't Do.
I would call this MAGIC, but it's closer to self determination.
* Ops with two PMCs will need to start by checking to see if they ought
to hand the method call off to the more important class.
* Every method with two arguments (all but get/set) need an extra "order"
parameter, so as to avoid duplication of code for
repeat P0, "const", P1
repeat P0, P1, "const"
Actually, that's a bad example, as the second should really not happen
but repeat P0, P1, 123 might, and should be allowed too, either way
both have to go through P1's vtable. A better example would be...
mul P0, 12, P1
mul P0, P1, 12
Which might not be as communative as you think, depending on what P1
wants to do with '*', think dynamic.
so we'll end up with something like:
void divide (PMC* value, INT(BOOL?)VAL reversed,PMC *dest) {
if (value->flags & CARES) {
if value cares more than me, then...
despatch to value, reverse order
}
if (reversed) {
dest->vtable->set_number( etc... )
}
else {
you get the idea
}
}
Hopefully that made sense...
Alex Gough
