Skip to content
Browse files
Refactor Producer; unravel EmitIterator wrappings
Stack traces were getting unecessarily cluttered with wrappings in
EmitIterators during transformations. To flatten the traces,
EmitIterator was migrated into Producer. The ideal implementation is a
Producer with both a public and protected constructor -- public to
accept AsyncIterators from the outside world, and protected with
an exposed scheduler for transformations.

From language limitations listed in the PS, the implementation settled
on static factory methods to interface with the outside world (::create
and ::create_producer for this and Producer<Tv> respectively) with a
protected constructor for use by transformations. The class remains
__ConsistentConstruct even with the ugly constructor, so that
expectations that most operations conserve the derived-ness of the
class are preserved. Sadly, this can't be all operators: any operators
that change the generic type must return concrete Producers because of
the lack of a derived_class<Tv> equivalent.


Hack unfortunately does not permit the overloaded constructor from the
ideal implementation. Firstly, overloading of most functions is not
allowed. The constructor can be over_ridden_ in subclasses with a
different argument set, which looks a lot like overloading. However,
the visibility of this constructor must be at least as visible as the
parent, so the public scope must get the same constructor as the class
if it does at all.

Secondly, constructors cannot be overloaded in the same class. Again,
ultimately what is needed is the ability for operators to call the
more restricted, richer constructor to make the object, with the
public only exposed to the constructor that accepts `AsyncIterator`.
However, because the parent constructor is necessarily shadowed by
the `self` one by the first limitation, there is no way to have
these two constructors coexist.

It makes sense why arbitrary methods can't create a self or static
objects with the parent constructor, since that constructor might not
be complete for the descendant's properties.

Finally, static methods can't construct objects. This is fairly
common, but it's not actually so necessary. If we could mark certain
static methods as "pseudo-constructors", then they could spawn an
uninitialized object, do its construction and _return_ that object
rather than solely being a mutator as regular constructors are.
  • Loading branch information
acrylic-origami committed Apr 2, 2017
1 parent f2121e3 commit 3faa3ed644616041a4096cb14e2dd2cfba0ea432
Showing with 288 additions and 307 deletions.
  1. +0 −265 src/Collection/EmitIterator.php
  2. +286 −40 src/Collection/Producer.php
  3. +1 −1 src/Producers/HTTPProducer.php
  4. +1 −1 src/Producers/ReadFileProducer.php

This file was deleted.

0 comments on commit 3faa3ed

Please sign in to comment.