id	summary	reporter	owner	description	type	status	priority	milestone	component	version	severity	resolution	keywords	cc	lang	patch	platform
811	"[RFC] Deprecate ""new Iterator"" form for creating Iterators."	bacek	bacek	"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"	RFC	closed	normal		core	1.3.0	medium	done