Non-pipeline component programming

[David Ledez via Digitalmars-d]

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, 
> 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