I loved reading Walter's component programming article in Dr.
Dobb's [0] in late 2012. I had missed H. S. Teoh's mid 2013
article on calendar textual formatting using the component
approach [1], but fortunately Ali brought it to my attention
recently, and I also find it absolutely fascinating!
I think what's most interesting with Teoh's article (and I think
that was Ali's point when he mentioned the article to me) is that
the calendar example is not as an obvious target for the
component approach, or at least that the design and
implementation is not as obvious for someone new to that approach.
Now, while Teoh's example is much more complex than Walter's,
both examples are for cases of pipelined problems (source ->
filter1 -> filter2 -> sink). What I have been wondering during
the last few days is how much this "component programming"
approach could be applied to scenarios where you would normally
have a jumble of objects. For instance, try to picture a game or
simulation where spaceships fire at each other, pick up objects,
communicate, and so on, or something like that. My instinct would
be to code a solution which would be classified as typical OOP
code. Would it be possible to come up with a solution that would
be more in the spirit of "component programming"? Or are such
solutions only practical/applicable for pipeline-like scenarios?
--
[0]
http://www.drdobbs.com/architecture-and-design/component-programming-in-d/240008321
[1]
http://wiki.dlang.org/User:Quickfur/Component_programming_with_ranges
- Non-pipeline component programming Luís.Marques
-