Dear T,
I've read with a great attention your reply regarding ECS and
OOP. You mention that you work on high-dimensional polytope and a
data structure able to support fast topological query with
compact storage. I would be very interested in having a look to
your data structure. Do you have any document about your design
and the concepts? Any github?
This thred is really extremely instructive. I m looking forward
to reading your reply.
Regards,
- David -
On Wednesday, 12 February 2014 at 17:38:30 UTC, H. S. Teoh wrote:
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
