Re: "Reader" as alternative to Iterator

Thanks everyone so far for the replies! I think I need to do some "homework", and come back with benchmarks and provide real examples. I remember that the overhead did make a difference in performance, but I should back that up with real data. For now just some inline replies. On Mon, Jul 3, 2017 at 3:42 PM, Sara Golemon <pollita@php.net> wrote: > On Sun, Jul 2, 2017 at 10:49 PM, Andreas Hennings <andreas@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. Yes, the adapters were just blind proxies. In my own library I had dedicated reader types like XmlElementReaderInterface, RowReaderInterface (e.g. for CSV), AssocReaderInterface, ObjectReaderInterface, each with their own ->read() methods like ->getElement(), ->getRow(), ->getAssoc(), ->getObject(). So I ended up writing a distinct iterator adapter for each reader type. The different interfaces were helpful to prevent using a reader of the wrong type. But we would lose this anyway if this was implemented in core. All the methods would all collapse into just one method ->read(). Maybe some PhpDoc magic could help the IDE to distinguish the reader type. Currently my IDE does not support such a thing.