You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Since the systems we deal with are horizontally = a network of actors and vertically = a hierarchy, or a fractal of actor networks, it would be nice to have a nice query language to select actors like we have in the web world. I think it'll lead to better, complex use cases like we have in CSS. Here's what I think it could look like (instead of systemId we can have id and id can become name or type, but type could be confusing - nomenclature can be done later, just want to throw this idea in the ether right now). I'll use the word DAM (Document Actor Model) to represent this fractal of actor networks in examples below -
State nodes = system.get(":state") (instead of . to represent state, using the CSS convention :)
By id = system.get("#bulb") (one particular bulb with an id of bulb)
By class = system.get(".bulb") (all bulbs existing both vertically and horizontally)
Decendants = system.get(".bulb :red") (all bulbs that are currently in red state and are decendants of .bulb(s))
Child = system.get("#counters > :stopped") (all direct children of a particular counter that are in stopped state).
Similarly, other selectors from CSS (like ~ for general sibling, + for adjacent sibling).
Thoughts -
Maybe, system.get should be replaced by query so it becomes query(":state") or const bulbs = query(".bulb").
With this method, every actor in the network and all of its states will be query-able and classes will bring a lot of convenience, like sending an event to all selected matches of a class in a short line would be nice.
It'll be easier to grasp conceptually for newcomers because pretty much everyone knows the selectors from CSS.
And, maybe a hot take - I personally think that a statechart is conceptually a little different from an actor network because a statechart describes exactly the behaviour that it produces but an actor network creates a new behaviour that emerges out of interactions of actors within the graph - which too can be modelled somewhat by another statechart, but the statechart won't capture all aspects of the interaction because it describes the purpose from one lens / perspective. The system created by a network of actors can have unintended states.
Example: A light bulb's behaviour can be abstractly described by a statechart with onoff states, but it can also be described as an emergent phenomenon due to interaction of its components (filament could be one actor, electricity source could be another and it could be electrons all the way down the hierarchy). So I think Actor network communications should be treated as a separate problem and communication within a statechart should be treated differently, even though all actors are individually statecharts - the network they make is not a statechart. But I may be wrong about this, I have to read up on it (please share books-to-read if you know any so that I can one day contribute to stately as well).
reacted with thumbs up emoji reacted with thumbs down emoji reacted with laugh emoji reacted with hooray emoji reacted with confused emoji reacted with heart emoji reacted with rocket emoji reacted with eyes emoji
-
Okay, hear me out!
Since the systems we deal with are horizontally = a network of actors and vertically = a hierarchy, or a fractal of actor networks, it would be nice to have a nice query language to select actors like we have in the web world. I think it'll lead to better, complex use cases like we have in CSS. Here's what I think it could look like (instead of
systemId
we can haveid
andid
can becomename
ortype
, buttype
could be confusing - nomenclature can be done later, just want to throw this idea in the ether right now). I'll use the wordDAM
(Document Actor Model) to represent this fractal of actor networks in examples below -.
to represent state, using the CSS convention:
)id
= system.get("#bulb") (one particular bulb with anid
of bulb)class
= system.get(".bulb") (all bulbs existing both vertically and horizontally)red
state and are decendants of .bulb(s))stopped
state).~
for general sibling,+
for adjacent sibling).Thoughts -
system.get
should be replaced byquery
so it becomesquery(":state")
orconst bulbs = query(".bulb")
.classes
will bring a lot of convenience, like sending an event to all selected matches of a class in a short line would be nice.And, maybe a hot take - I personally think that a
statechart
is conceptually a little different from anactor network
because a statechart describes exactly the behaviour that it produces but an actor network creates a new behaviour that emerges out of interactions of actors within the graph - which too can be modelled somewhat by another statechart, but the statechart won't capture all aspects of the interaction because it describes the purpose from one lens / perspective. The system created by a network of actors can have unintended states.Example: A light bulb's behaviour can be abstractly described by a statechart with
on
off
states, but it can also be described as an emergent phenomenon due to interaction of its components (filament could be one actor, electricity source could be another and it could be electrons all the way down the hierarchy). So I think Actor network communications should be treated as a separate problem and communication within a statechart should be treated differently, even though all actors are individually statecharts - the network they make is not a statechart. But I may be wrong about this, I have to read up on it (please share books-to-read if you know any so that I can one day contribute to stately as well).Beta Was this translation helpful? Give feedback.
All reactions