Creating a GatingProjection
A GatingProjection can be created using any of the standard ways to create a projection,
or by including it in the specification of an InputState or
OutputState . If a GatingProjection is created explicitly (using its constructor), its receiver
argument can be specified as a particular InputState or OutputState of a designated Mechanism, or simply
as the Mechanism. In the latter case, the Mechanism’s primary InputState will be used. If the
GatingProjection is included in an InputState or OutputState specification, that State will be assigned as the
receiver. If the sender and/or receiver arguments are not
specified, its initialization is deferred.
When a GatingProjection is created, its full initialization is deferred until its
receiver have been fully specified. This allows
a GatingProjection to be created before its
receiver have been created (e.g., before them in a
script), by calling its constructor without specifying its sender or receiver arguments. However, for the
GatingProjection to be operational, initialization must be completed by calling its
deferred_init method. This is
not necessary if the State(s) to be gated are specified in the gating_signals argument of a GatingMechanism, in which case deferred initialization is completed automatically by the
GatingMechanism when it is created.
A GatingProjection cannot be executed directly. It is executed when the InputState or OutputState to which it
projects is updated. Note that this only occurs when the Mechanism to which the State
belongs is executed (see Lazy Evaluation for an explanation of “lazy” updating). When a GatingProjection
is executed, its
function gets the
sender and conveys that to its
receiver. This is used by
receiver to modify the
value of the State gated by the
GatingProjection (see Modulation, InputState Execution and OutputState
Execution for how modulation operates and how this applies to a InputStates and OutputStates).
The changes in an InputState or OutputState’s
value in response to the execution of a
GatingProjection are not applied until the Mechanism to which the State belongs is next executed;
see Lazy Evaluation for an explanation of “lazy” updating).