Non-pipeline component programming

[Zoadian]

We're currently working on an Entity Component System for D ( 
https://github.com/Zoadian/nitro)

Here some good explanations:

http://t-machine.org/index.php/2007/09/03/entity-systems-are-the-future-of-mmog-development-part-1/

http://www.richardlord.net/blog/what-is-an-entity-framework



On Tuesday, 4 February 2014 at 04:12:49 UTC, Luís Marques 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!
>
> 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?
>
> --
>
> [0] 
> http://www.drdobbs.com/architecture-and-design/component-programming-in-d/240008321
>
> [1] 
> http://wiki.dlang.org/User:Quickfur/Component_programming_with_ranges