On Sun, Jul 2, 2017 at 10:49 PM, Andreas Hennings <andr...@dqxtech.net> wrote: > (I wanted dedicated reader classes for different return types, e.g. > one "RowReader", one "AssocReader", one "ObjectReader". So here I > would need one adapter class per type. But let's focus on the simple > case, where you can use the same reader class.) > You need that anyway. If the current iterator returns one type and you want to transform that into another type, then you need something to actually do that. Having a reader interface won't magically know that you want to change the output type.
If I'm misunderstanding that, and you're saying that the output type of the original iterator is already different and you somehow need a different proxy to blindly pass through the different type then... No. You don't. A single reader adapter will handle whatever type you pass through it. > the adapters also make stack traces heavier to look at. > That is the only slightly compelling argument I've seen so far. Not compelling enough IMO. > The main purpose of the generator syntax is to simplify the code. The > need for userland adapters defeated this purpose. > ONE adapter, which lives in a library that you don't touch once it's written. That doesn't defeat your purposes at all. That is, in fact, identical to having done the implementation in the core, expect when done in userland you have the opportunity to use it tomorrow rather than in December, and the ability to fix any bugs immediately rather than on a release cycle. > Native readers would have made generators worthwhile for my use case. > You've yet to demonstrate that they are not worthwhile. > The idea of "dedicated reader types" e.g. Reader<MyClass> could be > added to "Open questions".. > You have yet to demonstrate the need for dedicated and/or templatized reader types. -Sara -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
