Sorry for this belated reply, I have been rather busy with other matters.
On Tue, Feb 04, 2014 at 04:12:48AM +0000, [email protected] wrote: > 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! Thanks! > 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? [...] I would say that while it's insightful to apply different paradigms to solve the same problem, one shouldn't make the mistake of shoehorning *everything* into the same approach. This is what Java does with OO, for example, to the detriment of every other paradigm, and frankly, after a while all those singleton classes with static methods just start to smell more and more like ways of working around the OO rather than with it. Having said that, though, the component approach is highly applicable, often in unexpected areas and unexpected ways, esp. when you couple it with D's range-based concept. There are certainly algorithms where it makes more sense to treat your data as a graph rather than a linear sequence of nodes, but it's also true that a good percentage of all code is just variations on linear processing, so pipelined component-style programming would definitely be applicable in many places. And nothing says you can't intermix component-style code with OO, or something else. One key insight is that sometimes you want to separate the object itself from a range over that object -- for example, I work with polytopes (higher-dimensional analogues of polygons and polyhedra), and it's useful to have, say, a range over all vertices, or a range over all edges, but it's also useful to separate these ranges from the polytope itself, which can be stored in a more compact form, or in a form that's more amenable to fast queries, e.g., find all faces that contain vertex X without needing to iterate over every face in the polytope (which you'd end up doing if you use filter() on the range of all faces). The query function can return a range over faces, so that it can be piped into other range-based functions for further processing. Thus, you can have a mix of different paradigms complementing each other. The other underlying theme in my article, which is also one of the key points of the Jackson Structured Programming that I alluded to, is the identification and separation of mismatching structures in order to simplify the code and eliminate code smells caused by ad hoc methods of structure conflict resolution (boolean flags are a common symptom of this malady). This isn't limited to pipelined programs, but applies in general. One could analyze OOP in this way, for example. OO lore says that objects should be cohesive and loosely-coupled -- we could say that cohesiveness means that the data stored in the object has corresponding structures, and loose coupling means that if an object's data has conflicting structures, it's time to consider splitting it into two different objects instead. T -- I've been around long enough to have seen an endless parade of magic new techniques du jour, most of which purport to remove the necessity of thought about your programming problem. In the end they wind up contributing one or two pieces to the collective wisdom, and fade away in the rearview mirror. -- Walter Bright
