Changes between Version 1 and Version 2 of KeysRefactor

Show
Ignore:
Timestamp:
07/30/09 23:32:36 (12 years ago)
Author:
bacek
Comment:

--

Legend:

Unmodified
Added
Removed
Modified
  • KeysRefactor

    v1 v2  
    1111Such {{{FooKeyItem}}} will implement {{{get_foo}}} vtable methods, freeze/thaw and nothing else. We don't need FloatKeyItem because float keys are meaningless. 
    1212 
    13 3. Re-implement Key as: 
     133. {{{FooKeyItem}}} will not be directly constructable by throwing exceptions from {{{init}}} and {{{init_pmc}}}  
     14 
     154. Re-implement Key as: 
    1416 
    1517  a. RPA for storing *KeyItem. 
     
    1719  b. Various {{{push_foo}}} vtables to create specific FooKeyItem and append it to path. 
    1820 
     21 
     22=== Pros === 
     23 
     241. Keys PMC become almost equal to all other PMC in terms of handling (especially in PBCs). 
     25 
     262. Each {{{FooKeyItem}}} will have clean set of responsibilities. 
     27 
     283. It will speed-up keys handling slightly because we'll avoid big switch statements in each Key.foo vtable methods. 
     29 
     304. 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 
     415. Making mistake in Keys creating/using will be almost impossible. 
     42 
     43=== Cons === 
     44 
     45Someone will have to patch IMCC to support new Keys. 
     46