Re: Re: Making all Traversables an Iterator or IteratorAggregate

Hey Sara, > Am 12.05.2020 um 14:49 schrieb Sara Golemon <pollita@php.net>: > > On Tue, May 12, 2020 at 3:26 AM Nikita Popov <nikita.ppv@gmail.com> wrote: >> // WeakMap::getIterator(): Iterator >> ZEND_METHOD(WeakMap, getIterator) >> { >> if (zend_parse_parameters_none() == FAILURE) { >> return; >> } >> zend_create_internal_iterator_zval(return_value, ZEND_THIS); >> } >> > Given that the body of this method seems to usually (always?) be the same, > why not define it in InternalIterator and allow it to be inherited? Good idea. >> There's some bikeshed potential here regarding the class name. >> > Not personally over-picky, but I do agree that "Internal*" is a bit > awkward. Unfortunately there's not much that's better and appropriate for > exposing to scripts. This might be one of those rare occasions where > exposing "Zend" into userspace makes sense. "PHP" is overloaded into > several meanings that are significant for userspace developers, but > something like "ZendIterator" might convey the right level of "This has to > do with the engine, please move along". Or maybe go verbose: > 'IteratorForExtensionClassImplementations'. :p We call the engine Zend, but eih, that's a rather internal detail we mostly don't leak into userland, and I wouldn't do it here either. InternalIterator is the better choice I think. >> ZEND_ASSERT(scope->get_iterator != zend_user_it_get_new_iterator); > > Does this mean that if I do class Foo implements InternalIterator > {} in a > script, I can assert (crash) PHP? I don't see anything obvious (at a > glance) preventing me from inheriting from InternalIterator. The class is marked final, so userland won't be able to directly extend it. (zend_ce_internal_iterator->ce_flags |= ZEND_ACC_FINAL;) Bob