Ticket #761 (closed RFC: done)
[RFC] Keys/Iterator deuglyfying.
|Reported by:||bacek||Owned by:||bacek|
<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.
Note: See TracTickets for help on using tickets.