[Embedlets-dev] Event versus State-driven systems

[Andrzej J. T. <an...@ch...>]

I think Chris said (or was it Ted):

> Your point is accepted. I was digressing to a more general discussion of
> event vs state driven systems because I have run into some issues on this
> front.

Turing's Law would imply that all applications are both state and event based 
at some level.  I see no clash between these two.  In fact, I would suggest that 
applications need both to function. However, some people do not explicitly 
differentiate between the two, and as the lines blur, therein start the 
arguments.

Almost all but the most trivial programs have to keep track of state of some 
sort, whether that is of a physical device on a production line, bank account 
balance, user shopping card or whatever.  The key is what causes this state to 
change?  The receipt of an "event" (I'm using the term in a generic sense).  
The physical device tripped a sensor switch, a deposit was received or the 
user clicked on the "checkout" button.

My recent suggestion that we split the Context objects away from the 
Embedlet code (and not store state in the embedlet instance variables) is a 
manifestation of this.  The Context objects are responsible for keeping track of 
state.  The Embedlet Events (and code that produces events) are responsible 
for triggering state changes.  One is data-oriented.  The other is process-
oriented.  And it's typically a "good thing(tm)" to keep the two separate and 
distinct in application design, since it makes for clean and maintainable code.

I think trying to choose one paradigm or the other is nonsensical, since you 
typically need both in any real-world situation.



Andrzej Jan Taramina
Chaeron Corporation: Enterprise System Solutions
http://www.chaeron.com