Dan Sugalski wrote:
> *) Spec the vtable changes
Starting from my proposal ...
Subject: [RFC] 2. Proposal for _keyed opcodes
.... I have some more implementation details, WRT _keyed.
- An aggregate should provide these vtable methods:
* entry_type ... get info about the aggregates storage entry:
possible values are:
- int ... e.g. (packed) int array like current intlist
- float ... (packed) float
- UnionVal
- TypedUnionVal ... current HASH_ENTRY
- PMC
* get_entryp(PMC *key) ... get a pointer to an aggregates store entry
of above type, resolve compound keys if necessary
* get_entryp_int(INTVAL intkey) ... optimized version
These 3 methods ought to be enough, to implement all current _keyed
methods. And, with the proposed keyed ops, they should be usable for all
combinations of _keyed access.
get_integer_keyed => i = get_entryp(key)->u.int_val (for Union)
set_integer => get_entryp(key)->set_integer(i) (for PMC)
get_integer_keyed_int: i = *get_entryp(idx) (intarray)
....and so on
Aggregates that support autovivification have one additional method:
* set_entryp(PMC *key) which is the same as the get_entryp() accept, it
tells the aggregate that usage is LHS and that it might autovivify
intermediate aggregates. An aggregate not supporting this, sets both
methods to get_entryp().
Based on intlist.pmc (s. Subject: "[PATCH] direct accesss for intlist 10
times faster") we could implement intarray (packed int) floatarray
(packed float) array (PMC with bounds checking) and perlarray.
GC considerations: In a keyed access sequence the pointers returned by
get_entryp must not move (vv the underlaying store of course). To
simplify this goal, I would turn off GC during string_compare (used by
PerlHash).
Comments welcome,
leo
