<cite author="Dan" date="2002-09-23"
subject="Of variable, values, and vtables">
...
*) Spec the vtable changes
...
The variable/vtable stuff should be done in the next day or two.
</cite>
More threads with $subject:
- Variable/Value split prelims
- [RFC] Buffer/PMC unification, variable/value split, tied scalars
As "the next day or two" is almost gone, I would like to summarize this
thread and maybe start feeding patches WRT this.
- a "variable" consists of 3 parts: name, variable, value
- the 2 latter are now handled in one go in our vtable funcs
- variable and value access should be separate operations (think tie)
- 2-stage access (get_var->value->get/set_xxx) can be avoided for plain
variables by duplicating the value vtable meths to the var vtable.
Things to be considered:
- tied variables
- references
- objects
- aggregates/_keyed access
- ...
Proposal for struct _vtable:
base_vtable
var_vtable
val_vtable
prop_vtable
...
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.
Proposal for vtable.tbl
[section]
function()
...
[section]
...
First step in changes would be hiding current obj->vtable->meth calls
outside classes by some macros:
CALL_VTABLE_0(meth, interp, pmc)
CALL_VTABLE_1(meth, interp, pmc, arg1)
CALL_VTABLE_2(meth, interp, pmc, arg1, arg2)
...
Comments needed and welcome,
leo
