Non-pipeline component programming

[Mike Parker]

On Wednesday, 5 February 2014 at 15:29:14 UTC, Luís Marques wrote:

>
> Still, I wonder how related to the (pipelined) component 
> approach described by Walter and Teoh this ECS approach really 
> is. Perhaps more specifically, I wonder if the ECS approach 
> also allows using a lot of the std.algorithms, like was done in 
> the pipelined component approach, and in the calendar example 
> in particular.
>

Conceptually, it's not related. The only similarity is the use of 
the word "component." An ECS is concerned with breaking 
traditional objects into disparate, composable parts. This can be 
combined with the concept of Data-Oriented Programming (DOP), to 
improve cache locality when iterating entities, by storing all 
components of the same type in a contiguous block of memory. Then 
rather than iterating an array of entities and calling a setFoo 
method, you can instead more efficiently iterate an array of Foos 
independent of each entity.

The pipelined component concept is about chaining a set of 
operations to transform a dataset where the output of one 
transformation is the input to the next. Here, the "components" 
are not the data but the transformations, which can be swapped in 
and out, reordered, or added to and removed from the chain.

A cursory look at Nitro suggests they are using an ECS with DOP. 
Given that they're providing ranges for iterating the data, it 
will fit into D's range-based component pipelines (std.algorithm 
and such).