VariableBindings.h header

#include <ew/app/expression/VariableBindings.h>

Namespace ew::app::expression

CountContext struct

struct ew::app::expression::CountContext

Where a run stands, for the condition names that ask about the PATH rather than the world.

Separate from StoryCounts because two of the four names – VISITS and SCENE_VISITS – mean "here", and "here" is not something StoryCounts knows: it holds how often every node was reached, while which one the reader is standing on belongs to the playthrough.

Members

const ew::app::branching::StoryCounts* ew::app::expression::CountContext::counts = nullptr

What the run has done so far; nullptr where a condition may not ask. Not owned.

ew::core::foundation::BranchNodeId ew::app::expression::CountContext::node

The node the reader is standing on, which VISITS reports.

ew::core::foundation::ContentId ew::app::expression::CountContext::scene

The scene they are in, which SCENE_VISITS reports.

VariableBindings class

class ew::app::expression::VariableBindings

The names a branching condition may use: the story's variables, as the reader's playthrough currently holds them.

A variable is named as it is written in the Variables list. Where that name has spaces, an underscore stands in for each – has key is typed has_key – which is the convention Chat Mapper settled on for the same reason: an author should not have to rename their variables to be able to test them.

A Flag resolves to 1 or 0, so hasKey, hasKey = TRUE and NOT hasKey all read correctly. A declared variable the state does not carry resolves to its declared initial value rather than an error: the declaration is what the author wrote down, and a walk that has not reached the node which sets it is exactly the case a condition is there to handle. The world is reachable too. A condition may name any object – gold >= @Sword_of_Rhys.price – through the same resolver a validation rule uses, so a branch can depend on the world the story is set in and not only on the counters the author remembered to declare. A variable's name is looked for first, so nothing already written changes meaning.

The run is reachable too, when a caller offers one – see setCounts.

Members

ew::app::expression::VariableBindings::VariableBindings(const std::vector< ew::core::branching::Variable > &variables, const std::map< ew::core::foundation::VariableId, ew::core::branching::VariableValue > &state, const WorldResolver *world=nullptr)

Binds variables, read at the values state currently holds. world resolves object names, or nullptr where a condition may name only variables.

void ew::app::expression::VariableBindings::setCounts(const CountContext &context)

Lets this condition also read TURNS, CHOICE_COUNT, VISITS and SCENE_VISITS from context.

Opt-in rather than always available, because a VALIDATION rule has no run. Offering a rule author TURNS would let them write an assertion that can never be checked, and answering it with 0 would be worse: a rule that quietly holds for a reason that is not true. A playthrough calls this; the continuity validator does not.

bool ew::app::expression::VariableBindings::isNameStart(QChar character) const override

Adds the object sigil and the path characters when a world was given.

bool ew::app::expression::VariableBindings::isNameCharacter(QChar character) const override

Adds the path characters when a world was given.

std::optional< std::vector< ew::core::expression::Value > > ew::app::expression::VariableBindings::resolve(QStringView name, QString &error) const override

Resolves one variable name, then an object path.

QStringList ew::app::expression::VariableBindings::names() const override

Every variable's name, spelled the way a condition must type it, and every object.

Functions

QString ew::app::expression::expressionName(const ew::core::branching::Variable &variable)

The name variable is typed as inside an expression: its own name with each space replaced by an underscore.