# `Monty.Frameworks.Actions.Action`
[🔗](https://github.com/d-led/ex.tbp.monty/blob/v0.1.0/packages/ex_tbp_monty_core/lib/monty/frameworks/actions/action.ex#L1)

Something an agent can be told to do.

Mirrors `tbp/monty/frameworks/actions/actions.py::Action`, which is a protocol
every action satisfies rather than a class they inherit from: an action is a
name and a bag of parameters, and what makes it an action is that an
environment knows how to perform it.

Monty's `__iter__` yields the name first and then every parameter, which is
exactly what `to_map/1` answers — that map is the JSON object an action
crosses a boundary as, and `...Actions.ActionJSONDecoder` reads it back.

Monty's `sample/3` and `act/2` are not here: sampling needs the action
samplers and acting needs an actuator, and both belong to whatever environment
performs the actions. The `*ActionSampler` and `*Actuator` protocols are
therefore `:excluded` in the module map, each with its reason: sampling is the
samplers' own `sample_<action>` functions, and acting is the carried world's,
reached through `Monty.Simulators.Port`.

# `t`

```elixir
@type t() :: struct()
```

# `name`

```elixir
@callback name() :: String.t()
```

The action's name, as it appears in a configuration or on the wire.

Snake case of the module name, as Monty's `action_name()` is the snake case of
the class name.

# `to_map`

```elixir
@callback to_map(t()) :: map()
```

The action as a map: its name under `"action"`, then every parameter.

A `dict(action)` in Monty, and the object an action is sent as.

---

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