|Version 3 (modified by bacek, 4 years ago)|
Good idea. Will not work. Consider next PIR code:
$S0 = "foo"() $P1 = $P0[$S0]
In this case [$S0] will have type KEY_string_FLAG | KEY_integer_FLAG but store integer value of used register. I need something different. Or not to touch Keys at all and treat them as "unavoidable evil"...
Idea of refactoring Key PMC
Current Keys are messy and incomprehensible. So there is idea of refactoring them into something more sane.
Keys currently serve only one purpose: navigate in nested containers. Iteration over containers was removed as part of key_revamp branch. To support this functionality more implicit and in clean way we will:
1. Add KeyItem interface class to represent single abstract step.
2. Implement StringKeyItem, IntegerKeyItem and PMCKeyItem to store concrete value for each step. Such FooKeyItem will implement get_foo vtable methods, freeze/thaw and nothing else. We don't need FloatKeyItem because float keys are meaningless.
3. FooKeyItem will not be directly constructable by throwing exceptions from init and init_pmc
4. Re-implement Key as:
- RPA for storing *KeyItem.
- Various push_foo vtables to create specific FooKeyItem and append it to path.
1. Keys PMC become almost equal to all other PMC in terms of handling (especially in PBCs).
2. Each FooKeyItem will have clean set of responsibilities.
3. It will speed-up keys handling slightly because we'll avoid big switch statements in each Key.foo vtable methods.
4. Run-time creation of keys will be simplified to something like
# We are creating [42;"foo";84;"baz"] key. $P0 = new ['Key'] push $P0, 42 push $P0, "foo" push $P0, 84 push $P0, "baz"
5. Making mistake in Keys creating/using will be almost impossible.
Someone will have to patch IMCC to support new Keys.