It seems that someone once again rediscovered the benefits of component programming, in the context of OOP, but (as usual) without the more mathematical and principled approach of something like ranges and algorithms:


"The purpose of FUs is to process input and produce output. FUs are transformational. However, FUs are not called and do not call other FUs. There is no dependency between FUs. Data just flows into a FU (input) and out of it (output). From where and where to is of no concern to a FU. This way FUs can be concatenated in arbitrary ways: (...) Each FU can accept input from many sources and produce output for many sinks: (...) Connected FUs form a flow with a start and an end. Data is entering a flow at a source, and it´s leaving it through a sink. (...) You could say, Flow-Orientation is about tackling complexity at its root cause: that´s dependencies. “Natural” dependencies are depicted naturally, i.e. implicitly. And whereever possible dependencies are not even created. Functional units don´t know their collaborators within a flow. This is core to Flow-Orientation. That makes for high composability of functional units."

BTW, I just wrote my DConf proposal. I've been experimenting with a different style of not-quite-OOP in a real project and so far I'm really happy with the results. I've been making use of Jean-Louis' openmethods.d library, as well as other D features and techniques. The result is a quite nice balance of simplicity, expressiveness and performance. I'm really looking forward to telling you all about it :-)

Reply via email to