Please sign in to comment.
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. PS 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...
Showing with 288 additions and 307 deletions.
Oops, something went wrong.