Changes between Version 1 and Version 2 of KeysRefactor

Timestamp:

07/30/09 23:32:36 (12 years ago)

Author:

bacek

Comment:

--

KeysRefactor

@@ -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.
 
-3. Re-implement Key as:
+3. {{{FooKeyItem}}} will not be directly constructable by throwing exceptions from {{{init}}} and {{{init_pmc}}} 
+
+4. Re-implement Key as:
 
   a. RPA for storing *KeyItem.
@@ -17 +19 @@
   b. Various {{{push_foo}}} vtables to create specific FooKeyItem and append it to path.
 
+
+=== Pros ===
+
+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.
+
+=== Cons ===
+
+Someone will have to patch IMCC to support new Keys.
+