id	summary	reporter	owner	description	type	status	priority	milestone	component	version	severity	resolution	keywords	cc	lang	patch	platform
761	[RFC] Keys/Iterator deuglyfying.	bacek	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"	RFC	closed	normal		core	trunk	medium	done