Documentation
    Preparing search index...

    Class SystemRegistry

    The §39 ordered set of simulation systems.

    Ordering rules:

    1. Systems run in ascending priority.
    2. Systems of equal priority run in registration order, always. The registry inserts each system before the first entry of a strictly higher priority instead of sorting, so equal priorities can never be reordered by a sort implementation (ground rule 5: deterministic iteration).

    Mutation rules, mirroring EventEmitter (§6b rule 3) so the two lifecycle surfaces behave the same way:

    1. A system registered during a fixed step does not run until the next fixed step: runFixedStep iterates a snapshot taken before the first system runs.
    2. A system unregistered during a fixed step is skipped for the rest of that step even though it is in the snapshot ("unregistered" must mean "will not be called again"), and its dispose runs immediately at the moment of unregistration.

    Failure rule:

    1. A system that throws propagates the error out of runFixedStep; the systems after it are skipped for that step. The registry itself is never corrupted — its bookkeeping unwinds in a finally, so the next runFixedStep runs the full set again. A simulation step that failed halfway is not silently completed: swallowing the error would leave the world in a half-stepped state that later steps would build on (WP-1.11 decision; matches EventEmitter's dispatch).
    Index
    • Installs runFixedStep as scheduler.onFixedStep and returns a function that puts the previous callback back.

      This is the whole of D5's seam: the scheduler is not modified, imported from, or subclassed — its public callback property is assigned, exactly as SchedulerOptions.onFixedStep would.

      The returned detach is idempotent and defensive: if something else has since replaced onFixedStep, detaching leaves that newer callback alone rather than clobbering it (WP-1.11 decision).

      Parameters

      Returns Detach

    • Unregisters every system, calling each dispose once, in reverse registry order — descending priority, with equal priorities disposed in reverse registration order — so teardown mirrors the §39 execution order, as disposeAll (§83) mirrors construction for resources. A dispose that throws does not stop the rest; the first thrown value is re-thrown afterwards.

      Returns void

    • Registers system, calls its initialize exactly once, and returns an idempotent unregister function.

      initialize is called after the system is inserted, so it may query the registry (including registering further systems) from the context.

      Parameters

      Returns Unregister

      RangeError if priority is not a finite number.

      Error if the same system instance is already registered — registering twice would call initialize twice and make dispose ambiguous (WP-1.11 decision; §39 describes a set of systems, not a bag).

    • Runs every registered system's fixedUpdate once, in registry order.

      Parameters

      Returns void

      Error if called while a fixed step is already running. A nested fixed step would advance the simulation twice for one TimeState and break replay (§34), and unlike a re-entrant event (§6b rule 4) there is no meaningful "later" to defer it to — the scheduler owns the step cadence (WP-1.11 decision).