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"..
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
