Changes between Version 3 and Version 4 of KeysRefactor

Timestamp:

08/03/09 09:39:37 (12 years ago)

Author:

bacek

Comment:

Unscratch KeysRefactor idea

KeysRefactor

@@ -1 @@
-=== Update ===
-
-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 ===
 
@@ -19 +8 @@
 1. Add {{{KeyItem}}} interface class to represent single abstract step.
 
-2. Implement {{{StringKeyItem}}}, {{{IntegerKeyItem}}} and {{{PMCKeyItem}}} to store concrete value for each step.
+2. Implement {{{StringKeyItem}}}, {{{IntegerKeyItem}}}, {{{PMCKeyItem}}} and {{{RegisterKeyItem}}} 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.
+{{{RegisterKeyItem}}} will store tuple {{{register_type, register_number}}} to reference particular register.
 
-3. {{{FooKeyItem}}} will not be directly constructable by throwing exceptions from {{{init}}} and {{{init_pmc}}} 
+3. {{{FooKeyItem}}} will not be directly constructable by throwing exceptions from {{{init}}} and {{{init_pmc}}}
 
-4. Re-implement Key as:
+4. {{{RegisterKeyItem}}} will be directly constructable and implement {{{set_integer_keyed_int}}} method to set {{{register_type}}} and {{{register_number}}}. 
+
+5. Re-implement Key as:
 
   a. RPA for storing *KeyItem.