Simon Cozens:
> I'm working on unbreaking it, patches welcome.
Unfortunately, it seems the way that key.c works is currently a lot more
broken than I suspected. :( This is going to take some time.
The plan, such as it is, is that a KEY* structure is an index, rather
than being an aggregate itself. Just like in an ordinary Perl hash, you
apply a KEY to an aggregate, and you get a value out. The KEY* and
KEY_PAIR* structures as they are are great, but none of the functions in
key.c make any sense under this interpretation.
If the KEY* has one KEY_PAIR element which is numeric, you've got an index
into an array; if it has one KEY_PAIR element which is a string or a PMC*,
you've got an index into a hash. If it has multiple KEY_PAIR elements,
you're dealing with a multidimensional hash or array.
In this model, then, the work of finding the appropriate index into the data
is pushed onto the PMC classes. So I'd expect to see something like this, in
an array class:
INTVAL get_integer_keyed(KEY* key) {
KEY_PAIR* kp;
INTVAL index;
PMC* value;
if (!key) {
return PMC->cache.intval; /* Length of the array */
}
kp = (key->keys)[0];
index = kp->cache.intval;
if (index > PMC->cache.intval) {
extend_array(PMC->value, index);
}
value = (PMC->data)[index];
return value->get_integer(INTERPRETER, value);
}
Does this make sense?
--
Putting a square peg into a round hole can be worthwhile if you don't mind a
few shavings. -- Larry Wall
