[RFC] Buffer/PMC unification, variable/value vtable split, tied scalars

[Leopold Toetsch]

Attached is a test program showing some features, how a PMC could look like in the future.

1)
PMCs/Buffer are both based on the same bufferlike structure - I called it Pobj (Parrot Object)
- There is no need, that all PMCs are of same size, the bufferlike code in smallobjects.c / headers.c takes care of these.
- mark/GC would be unified - marking all Pobj's does it.
- Eliminates a fair amount on now duplicate code.

Steps towards that would include:
- encapsulate flags and other Buffer/PMC members in accessor macros
- unify the BUFFER/PMC_xx_FLAGs
- unify mark and general code clean up

2)
Variable/value VTABLE split
As layed out by Dan, the access to a value inside a PMC has - in the general form - to be done in 2 separate steps:
- get the variable PMC (+ handle side effects like tied variables)
- get the value out of this PMC
The same rule holds for setting a value inside a PMC.

By splitting the VTABLE into different pieces, we can avoid to do these separate steps for plain scalars, which wouldn't need it.

Please have a look at »scalar_vt« and »tied_scalar_vt« in the test program, how this could work:
For plain scalars the first vtable->var.get_integer does it all - finito - like current operation. For tied scalars, the vtable has different entries, to accomplish both steps.

The test program shows additionally, how other methods would be implemented - they all are in the vtable->val part, calling vtable->var.get/set_{type} for obtaining/setting values.

Putting these methods into the vtable->val piece provides for a small vtable->var piece, which only holds (duplicates of) the direct get/set_{type} methods. So vtable duplication is minimal.

3) Tied scalars
Based on above scheme, the test program shows, how this actually works by tieing a scalar to a (fixed) function, which increments the value on each access. Using this tied scalar in an »add« methods does the right thing.

Unsolved - as mentioned in the program - is how to handle these now dynamically allocated vtable (pieces) WRT memory management. But we could probably allocate these vtable pieces as bufferlike small objects and keep them in pools. Many different PMCs (all of the same type/class) are having the same vtable anyway. Subclassing or tieing a variable would generate one or more new vtable pieces for this variable type.

Finally, the test program can be run in the parrot main dir by:

$ cc -o tt -Wall -g tt.c -Iinclude && ./tt

(The syntax for different platforms might differ ;-)

Please give it a try, to see implications for different platforms and - as always - coments welcome,

especially e.g.
- how would references fit, how will the look like
- objects and methods/attributes and subclassing
- and the whole and everything ...

Have fun,
leo