Skip to content

Latest commit

 

History

History
68 lines (67 loc) · 2.93 KB

do want.md

File metadata and controls

68 lines (67 loc) · 2.93 KB
Raw
  • specifying the initial edges as 1-dir node edges,
    • weights,
    • names,
    • action names (edge names are unique, action names are unique-to-source,)
    • the probability of an edge
  • the ability to list
    • a node's edges (in/out/both,)
    • whether a node is terminal,
  • to specify for a graph
    • min/max edge count,
    • whether to tolerate islands,
    • whether to links should be 1d/2d/either,
    • whether the state machine is fixed (not implementing for now,)
    • whether forcing (making a change outside the edge graph) is permitted (not implementing for now,)
    • whether names are allowed|disallowed|optional,
    • whether action names are allowed|disallowed|optional,
  • for non-fixed machines, (not implementing for now,)
    • to add edges,
    • to remove edges,
    • to remove nodes (and thus all the related edges,)
    • to have a sane way to validate afterwards
  • attached data,
    • which is transactionally applied,
    • which is available to all validation hooks,
  • validation hooks on
    • walking an edge,
    • entering/exiting a node,
    • changing data (which can happen with or distinctly from a transition, but always atomically w/ validation),
  • notification hooks on
    • any change,
    • enter/exit a node,
    • walk an edge,
    • execute a named action,
    • data change,
    • init,
    • non-matching event
  • the ability to generate
    • flowchart representations
      • prolly using viz.js (graphviz emscriptened to yerbaschmidt)
    • uml statechart representations?
    • sdl representations?
    • nfa representations? (see comments below, thanks @patater)
    • drakon representations?
    • harel statecharts?
  • the ability to
    • save a state machine state,
    • load/create from a state machine state,
    • validate an abstract state machine state,
    • keep and rewind a state history (thanks @kz),
    • autocreate an api (that is, action "melt" on machine auto-gets api method equiv .melt())
    • consume .dfa files?
    • compare two state machines?
    • check is_changing
  • improved nature of states (all thanks burny who isn't on gh zomg)
    • states as objects rather than strings
      • makes inheritance easier
      • makes heirarachy easier
      • makes state-associated data easier (eg walking state now has frame#)
      • makes underlying impl much harder
    • state subtypes
    • heirarchal states
      • triggered by subordinate on transfer callback to superior
      • "or polling"
    • multiple concurrent states (keanu mind blown.gif)
  • for convenience,
    • a fluent api for creation

difference between event and action: if action isn't handled, it's an error; if event, meh