[RFC] Keys/Iterator deuglyfying.

[bacek]

Hello.

<bacek> chromatic: I finally understood (fsvo) Keys.
 Biggest problem with Keys (from my POV) they used for 2 very different things.
 1. Describing path in nested aggregates.
 2. Iterate over aggregates.
<chromatic> Exactly.
<bacek> My .plan for deuglyfying them:
 1. Use keys only for paths.
 2. Made Iterator pure interface class.
 3. Implement HashIterator and ArrayIterator.
<chromatic> That sounds reasonable.
<bacek> 4. Use MULTIs for handling PMC/Key in (set|get)_*_keyed
 5. Remove all code left in Keys for support iterators.
 Any ideas objections?
 s/ / or /
<chromatic> #4 is the only part that concerns me at all, but 1 - 3, 5 are independent of that.
<bacek> (I will need HashIteratorKey though)
 What's wrong with #4?
<chromatic> It's a little more invasive.  That's all.
<bacek> Why? We have switch-based multi-to-vtable "optimiser".
<chromatic> Because I think that treating String PMCs, Keys, and RSAs as equivalent as Keys is a design flaw, not an implementation detail.
<bacek> it's only in Namespace. Not in Hash by itself
 Hash only handle Keys differently.
<chromatic> That's good.
 My biggest problem with Key is that it could contain so many different types of data it has to check on every access to figure out what to produce.
<bacek> Ok, I'll put this as RFC ticket and create branch for it.

Any comments/suggestions are welcome.

-- Bacek

[bacek]

Branch tt761_keys_revamp was merged into trunk in r40100. Resolving ticket.