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 <poll...@php.net> wrote:
> 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.

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.

-- 
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php

Reply via email to