# `Monty.ModuleMap.StandIns`
[🔗](https://github.com/d-led/ex.tbp.monty/blob/v0.1.0/packages/ex_tbp_monty_core/lib/monty/module_map/stand_ins.ex#L1)

What this application runs in place of a Monty class it has not written.

Two things do, and nothing else:

  * **the runtime** does the job of Monty's shell — `Monty`, whose concrete
    stepping is `MontyBase`, and `MontyForGraphMatching`, which owns the
    matching step and the vote round. Here those are processes
    (`Monty.Runtime.Model`) stepped by `Monty.Runtime.Step`, and the episode
    belongs to `Monty.Studio.Run`. That is a replacement on purpose, not a
    hole: the job is done — the step order, the goals through the attention
    system, the vote round, the counters and the terminal decision.
  * **the MuJoCo world** — Monty's `MuJoCoSimulator`, its agents and its scene
    objects are written here, in `priv/monty_py/world.py`, against `mujoco`
    rather than in Elixir: a renderer is a C library with a Python binding, so
    the scene cannot live in the BEAM. The behaviour is Monty's (the spec, the
    cameras, the semantic ids, metres and `wxyz` rotations); the code is this
    application's, and `Monty.Simulators.Mujoco.Simulator.MuJoCoSimulator` is
    the class a run steps. A Python file is therefore not evidence of an
    unported class — it is where this port had to stay Python.

A class in neither list has **no** stand-in, and a config naming it is
refused: an unwritten class is an error rather than a fake run wearing the
experiment's name (`Monty.Studio.Setup`'s findings say so on the page).

This module is the one place the answer is written down. `mix
monty.module_map.gen` copies it into the map as `stand_in` on each class, and
everything else — the studio's findings, `/modules` — reads it from there, so
a page and a refusal cannot disagree about what runs.

# `for_class`

```elixir
@spec for_class(String.t(), String.t() | nil) :: [map()]
```

What runs in place of this class, or `[]` when nothing does.

The answer is data — `kind: :module` naming an Elixir module that exists, or
`kind: :file` naming a path in this repository — with a sentence saying why,
because "replaced" and "missing" look the same from a table and mean
opposite things for a reader deciding whether an experiment can run.

# `in_the_world?`

```elixir
@spec in_the_world?(String.t() | nil) :: boolean()
```

Whether a class of this Python file is one the carried world implements.

`python` is either the file path inside the package, as the map records it, or
the dotted module path of a resolved class.

# `shell?`

```elixir
@spec shell?(String.t()) :: boolean()
```

Whether this class is one whose job the runtime does.

# `shell_classes`

```elixir
@spec shell_classes() :: [String.t()]
```

The classes whose job the runtime does, by Monty's own name for each.

---

*Consult [api-reference.md](api-reference.md) for complete listing*