ID and Class (and more selectors) for Actors

[a-y-u-s-h]

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

0. State nodes = system.get(":state") (instead of . to represent state, using the CSS convention :)
1. By id = system.get("#bulb") (one particular bulb with an id of bulb)
2. By class = system.get(".bulb") (all bulbs existing both vertically and horizontally)
3. Decendants = system.get(".bulb :red") (all bulbs that are currently in red state and are decendants of .bulb(s))
4. Child = system.get("#counters > :stopped") (all direct children of a particular counter that are in stopped state).
5. 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 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).