Front page | perl.perl6.internals |
Postings from October 2002
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
Thread Next