#761: [RFC] Keys/Iterator deuglyfying.
--------------------+-------------------------------------------------------
Reporter: bacek | Owner: bacek
Type: RFC | Status: new
Priority: normal | Milestone:
Component: core | Version: trunk
Severity: medium | Keywords:
Lang: | Patch:
Platform: |
--------------------+-------------------------------------------------------
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
--
Ticket URL: <https://trac.parrot.org/parrot/ticket/761>
Parrot <https://trac.parrot.org/parrot/>
Parrot Development
_______________________________________________
parrot-tickets mailing list
[email protected]
http://lists.parrot.org/mailman/listinfo/parrot-tickets
