Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:99697
Mailing-List: contact internals-help@lists.php.net; run by ezmlm
Received-SPF: error (pb1.pair.com: domain dqxtech.net from 209.85.223.171 cause and error)
MIME-Version: 1.0
In-Reply-To: <CAESVnVoQ-+mbUiXAUO1tsRzAqSGJnOnxba9qe=HAU-kqCyYTng@mail.gmail.com>
References: <CAH0Uv3Gx_OGBA4zwzE97mbK_VtwBtRCX3yn9JNv81VWtQbCYtA@mail.gmail.com>
 <CAESVnVoQ-+mbUiXAUO1tsRzAqSGJnOnxba9qe=HAU-kqCyYTng@mail.gmail.com>
Date: Mon, 3 Jul 2017 04:49:23 +0200
Message-ID: <CAH0Uv3EdyPRgcYXuFP5GVjPpx4+kga_HbE9zzbu1XsAVSMjJ-w@mail.gmail.com>
To: Sara Golemon <pollita@php.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: andreas@dqxtech.net (Andreas Hennings)

Well, on a current project I made an attempt to write different
adapters in userland.
I finally decided that the clutter is not worth.
So for this project I wrote everything as "readers", and not as iterators.

With a native solution, one could do this:

function generate() {
  yield 'a';
  yield 'b';
  yield 'c';
}

$it = generate();

while (FALSE !== $v = $it->read()) {
  print $v . "\n";
}

With a userland adapter, the code would read like this:

function generate() {
  yield 'a';
  yield 'b';
  yield 'c';
}

$it = generate();

// This is the added line.
$reader = new IteratorReaderAdapter($it);

while (FALSE !== $v = $reader->read()) {
  print $v . "\n";
}


This does add clutter and performance overhead.
In this example I'd say this is acceptable / survivable.

In the project I was working on, I have multiple layers of "readers":
- One layer to read raw data from a CSV file.
- One layer to re-key the rows by column labels.
- One layer to turn each row into an object, with structured
properties instead of just string cells.

With the "reader" approach, for each layer I would have one "reader
provider" class and one "reader" class per layer.
(In fact I have much more, but let's keep it simple)
Generator syntax would allow to have only one class per layer.
But with the additional adapter, we again increase the number of classes.
(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.)

In addition to more classes and more function calls (performance), the
adapters also make stack traces heavier to look at.

Overall, for this project, I decided that it was not worth it.

The main purpose of the generator syntax is to simplify the code. The
need for userland adapters defeated this purpose.
Native readers would have made generators worthwhile for my use case.

The idea of "dedicated reader types" e.g. Reader<MyClass> could be
added to "Open questions"..