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:
<http://geekswithblogs.net/theArchitectsNapkin/archive/2011/03/19/flow-design-cheat-sheet-ndash-part-i-notation.aspx>
"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 :-)
