revise Itertool design and initialisation

[Ichthyostega]

As Lumiera Architect,
I want a readable and optimally performant implementation core of the »itertools«,
to keep this pervasively used family of utilities in well maintainable shape.

Design review and polishing

The »itertools« were created early in the development of Lumiera — out of practical need and heavily inspired by Python — at that time the C++ language did not even offer a foreach-looping construct (and no λ either). And while the original design was somewhat clumsy, these utilities turned out to be wildly successful, drastically simplifying the code at various places. Meanwhile, the framework of iteration helpers was evolved much further; especially there is now the concept of a »state core«, and there is the much more elaborate TreeExplorer pipeline builder, which offers a lot of similar functionality (but is more heavy on the compiler and demanding for the human reader as well).

In its current form, the concrete »itertools« inherit from the Itertool template, which provides the iterator implementation, while the specific functionality is passed down as template parameter (CRTP). This is fine, just we can't define the operator++ properly in a baseclass, without knowing the type of the concrete iterator to return. This forces us to repeat the definition of the operator in each derived class

A possible refactoring would be:

• pass the type of the concrete tool down (CRTP)
• add a convention, that this concrete tool has to provide a member "Core" with appropriate typedef and a getter
• then access the core directly from the layered front-end.

Another possible refactoring places the Itertool class at front, requiring the core as template parameter, but providing a Builder class for the client code to construct this compound. In practice, Itertool instances are created by the convenience free functions anyway. The type would e.g. be Transforming<Iter, Val>::iterator, and this builder class would expose a static function build(src, trafoFunc). Expanding on that second idea, the internal communication protocol between Itertool and the functionality core could be remoulded to be identical to the protocol employed by IterStateWrapper — since the latter protocol is equivalent, but has proven to be much easier to understand and implement.

The first solution has the benefit not to change the interface, while the second probably creates much more readable Itertool implementation code (?)

[Ichthyostega]

ugly, but not an urgent problem right now. Pushing to future

[Ichthyostega]

Another aspect to validate is the usage of move semantics (see #942) — when done right, the convoluted initialisation and setup of an itertool usage can be reduced to „almost nothing“ by the optimiser....

[Undercover Agent]

Migration MasterTickets ⟼ Subtickets-plugin