Heya, After seeing all the bruhaha on the list about keyed-ness, I thought I'd try my hand at it, to see if I could get any farther before running up into the wall. :)
Here's my own list of questions...first, the main problem with keys, as I see it, is that there is no guiding PDD or spec that describes how they should work. As such, people can only learn from the code. And that's a mess. While basic key support is there, lots of things are half-implemented, or incorrectly implemented, and it's quite hard to get a coherent picture. At least, imho. Where are keys going to be stored? Currently, they exist only on the system stack, and key_new and key_clone are unused. Will we eventually have free-floating keys? Should we create support that causes them to be stored in small-object pools? I see that certain ops accept a type called KEY, which acts exactly like INT. And I mean *exactly*. It pulls data from INT registers, and even the 'k' and 'kc' type translate into accesses that look exactly like 'i' and 'ic'. Are we planning on having key creation and mutation operations? Where will these keys be stored in order to operate on them? INT registers? (Sorta how it is now, although it looks wrong). STR registers? (Means they need to be headered, DOD'ed, and a larger per-key size). Will they get their own registers, maybe only 8 deep? What about the possibility for constructing/operating on keys using a Key PMC. We could convert to/from real KEYs by using the PMC. This is basically just a sidestep of the above problem. Currently, I see: set_keyed_integer: PK* PI* *PI *PK set_keyed: PS* *PS PN* *PN set: PPPP What's the point of set_keyed versus set_keyed_integer naming? There doesn't seem to be any overlap at all, so set_keyed_integer could safely be named set_keyed. Can we safely remove "set PPPP", due to the relative inefficiency in constructing dummy PMCs to call it? Wouldn't it be more efficient to split the call into two "set PP*",and "setP*P" calls? Thanks, Mike Lambert
