I have to be quick, but just to keep things moving along...
(0) Leo writes
Whe we have:
set P0, 5
from this piece of code, we don't know, if we set the value of P0, or if
we set the value of the referenced object, where P0 points to. Only the
vtable knows, what we are assigning to.
(1) This "set" uses core.ops's
inline op set(inout PMC, in INT) {
$1->vtable->set_integer_native(interpreter, $1, $2);
goto NEXT();
}
which becomes core_ops.c's
static opcode_t *
Parrot_assign_p_i (opcode_t *cur_opcode, struct Parrot_Interp * interpreter) {
#line 676 "core.ops"
PREG(1)->vtable->set_integer_native(interpreter, PREG(1), IREG(2));
return (opcode_t *)cur_opcode + 3;
}
(2) Several classes implement set_integer_native.
classes/scalar.pmc has
void set_integer_native (INTVAL value) {
SELF->cache.int_val = value;
}
classes/array.pmc has
void set_integer_native (INTVAL size) {
list_set_length(INTERP, (List *) SELF->data ,size);
}
(3) A new reflector/reference class.
Say we were to create a new classes/reflector.pmc class, with the
intent that operations on the reflector object would be applied to the
object being reflected. An indirection.
Then we might give it a class method
void set_integer_native (INTVAL value) {
PMC *object_reflected = SELF->cache.pmc_val;
object_reflected->vtable->set_integer_native(...);
}
Ok. Let us completely ignore optimization at the moment. Let us
celebrate slowness.
Question ONE - What parts of the above code, if any, need to be
changed, simply and solely to address Dan's concern that we are being
"sloppy with variables and values".
(Based on Dan's comments, I do _not_ expect splitting the vtable into
parts to be part of the answer to this question.)
Mitchell
(Q2 will wait for another time)
