Non-pipeline component programming

H. S. Teoh hsteoh at quickfur.ath.cx
Wed Feb 12 09:36:36 PST 2014


Sorry for this belated reply, I have been rather busy with other
matters.


On Tue, Feb 04, 2014 at 04:12:48AM +0000, digitalmars-d-bounces at puremagic.com 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


More information about the Digitalmars-d mailing list