Nicholas Clark wrote:
base_vtable ... name, type, ... var_vtable ... get_integer, set_integer, ... val_vtable ... add, sub, ... prop_vtable ... property functions (set/getprop are different, depending on the existence of the property hash)The vtable pieces and the _vtable container struct should be pointers to constant memory, initialized similar to current class_init code.
A variable "has" or "isa" value and as PMCs are involved there is no plain value.Effectively a variable ISA value. So shouldn't val_vtable come first, so that we can create shorter vtables for values, such as values in aggregates?
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.
So per se, we don't have "values only" in e.g. aggregates, when PMCs are involved.
The naming of this pieces is of course not fixed. In my test program I had: var.get_integer and val.get_integer. The former is accessing the "variable" and - for plain scalars - also getting the value, alas our current get_integer. For "complex" scalars, the var_vtable just gets a PMC* and the val_part does the rest.
The order of the vtable pieces is not important. I proposed to use different vtable pieces for aggregates and scalars, but Dan is against this "references and the referenced objects should look alike". We will see when we try to implement references.
> Or is this vtable just for variables?
No - general vtable for everything.
For a more "solid" example, please have a look at my test program tt.c attached to my 2. mail in the mentioned "[RFC] ..." thread.
Also, if vtable pieces are in constant memory, how do we efficiently create singleton objects?
Objects would have allocated vtable pieces and some header flag noting this and/or a "overloaded" destroy vtable function. We need probably the same strategy for overloaded operators.
Nicholas Clark
leo
