#811: [RFC] Deprecate "new Iterator" form for creating Iterators.
--------------------+-------------------------------------------------------
Reporter: bacek | Owner:
Type: RFC | Status: new
Priority: normal | Milestone:
Component: core | Version: 1.3.0
Severity: medium | Keywords:
Lang: | Patch:
Platform: |
--------------------+-------------------------------------------------------
Hello.
Currently there is 2 ways of creating iterators:
1. $P0 = new 'Iterator', aggregate
2. $P0 = get_iter aggregate
As part of keys_revamp branch I start creating aggregate-specific
iterators. E.g. HashIterator, ArrayIterator, etc. Which leads to next code
in Iterator PMC:
{{{
VTABLE void init_pmc(PMC *aggregate) {
if (VTABLE_does(INTERP, aggregate, CONST_STRING(INTERP, "array"))
|| VTABLE_does(INTERP, aggregate, CONST_STRING(INTERP,
"hash"))
|| VTABLE_does(INTERP, aggregate, CONST_STRING(INTERP,
"string"))
) {
/* It's ugly hack... But I cant figure out proper way to do
it. */
PMC *real_iter = VTABLE_get_iter(INTERP, aggregate);
SELF = pmc_reuse_init(INTERP, SELF, VTABLE_type(INTERP,
real_iter), aggregate, 0);
return;
}
else {
/* Die horribly */
PARROT_ASSERT(!"Unsupported Aggregate for Iterator");
}
}
}}}
Main purpose of Iterator.init is create real iterator and "morph" to it.
It's error-prone, inconsistent and ugly.
My propose is to deprecate "new Iterator, aggregate" form of creating
iterators and left only VTABLE-based "get_iter" op.
--
Bacek
--
Ticket URL: <https://trac.parrot.org/parrot/ticket/811>
Parrot <https://trac.parrot.org/parrot/>
Parrot Development
_______________________________________________
parrot-tickets mailing list
[email protected]
http://lists.parrot.org/mailman/listinfo/parrot-tickets
