2017-07-03 4:49 GMT+02:00 Andreas Hennings <andr...@dqxtech.net>:
> 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"..
Hey Andreas,
what you're trying to do here seems to be premature optimization. While you
save a bunch of method calls, your I/O will be the actual bottleneck there.
It's entirely fine to implement such logic in userland.
Amp has a similar interface for its streams, but those have only
string|null as types. If you want to allow all values, you either need a
second method or need to wrap all values in an object.
http://amphp.org/byte-stream/#inputstream +
http://amphp.org/amp/iterators/#iterator-consumption
Regards, Niklas
