Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:99702
Mailing-List: contact internals-help@lists.php.net; run by ezmlm
Received-SPF: softfail (pb1.pair.com: domain golemon.com does not designate 74.125.82.49 as permitted sender)
MIME-Version: 1.0
Sender: php@golemon.com
In-Reply-To: <CAH0Uv3EdyPRgcYXuFP5GVjPpx4+kga_HbE9zzbu1XsAVSMjJ-w@mail.gmail.com>
References: <CAH0Uv3Gx_OGBA4zwzE97mbK_VtwBtRCX3yn9JNv81VWtQbCYtA@mail.gmail.com>
 <CAESVnVoQ-+mbUiXAUO1tsRzAqSGJnOnxba9qe=HAU-kqCyYTng@mail.gmail.com> <CAH0Uv3EdyPRgcYXuFP5GVjPpx4+kga_HbE9zzbu1XsAVSMjJ-w@mail.gmail.com>
Date: Mon, 3 Jul 2017 09:42:19 -0400
Message-ID: <CAESVnVotWoakXZBwRn87WAKbvd1cz9O8kS-omsii6nJFfz8S+Q@mail.gmail.com>
To: Andreas Hennings <andreas@dqxtech.net>
Cc: PHP internals <internals@lists.php.net>
Content-Type: text/plain; charset="UTF-8"
Subject: Re: [PHP-DEV] "Reader" as alternative to Iterator
From: pollita@php.net (Sara Golemon)

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.

> 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