Changes between Version 1 and Version 2 of KeysRefactor
- Timestamp:
- 07/30/09 23:32:36 (12 years ago)
Legend:
- Unmodified
- Added
- Removed
- Modified
-
KeysRefactor
v1 v2 11 11 Such {{{FooKeyItem}}} will implement {{{get_foo}}} vtable methods, freeze/thaw and nothing else. We don't need FloatKeyItem because float keys are meaningless. 12 12 13 3. Re-implement Key as: 13 3. {{{FooKeyItem}}} will not be directly constructable by throwing exceptions from {{{init}}} and {{{init_pmc}}} 14 15 4. Re-implement Key as: 14 16 15 17 a. RPA for storing *KeyItem. … … 17 19 b. Various {{{push_foo}}} vtables to create specific FooKeyItem and append it to path. 18 20 21 22 === Pros === 23 24 1. Keys PMC become almost equal to all other PMC in terms of handling (especially in PBCs). 25 26 2. Each {{{FooKeyItem}}} will have clean set of responsibilities. 27 28 3. It will speed-up keys handling slightly because we'll avoid big switch statements in each Key.foo vtable methods. 29 30 4. Run-time creation of keys will be simplified to something like 31 32 {{{ 33 # We are creating [42;"foo";84;"baz"] key. 34 $P0 = new ['Key'] 35 push $P0, 42 36 push $P0, "foo" 37 push $P0, 84 38 push $P0, "baz" 39 }}} 40 41 5. Making mistake in Keys creating/using will be almost impossible. 42 43 === Cons === 44 45 Someone will have to patch IMCC to support new Keys. 46