You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
This proposal is not yet completely finished. Consider it WIP!
Summary
This proposal introduces three lifetimes which can be applied on a region level. They define how long a process inside of such a region is alive.
The three lifetimes are
OnStack - a process will live only on the stack
It is completely thread safe and can always be offered, the restriction of process nodes not being allowed in stateless contexts can therefor be lifted entirely (same applies for pads).
AsParent - the lifetime of a process is tied to the containing patch
It is also always available. However there are some details to clarify what should happen if parent is set to OnStack and the delegate we're in doesn't get invoked immediately.
BySink - the lifetime is controlled by the sink
It is thread safe as well. However it is only available if the state gets passed explicitly by the caller. See below for details.
Visualization
In order to reason about a patch we need to be able to see what lifetime currently applies.
OnStack - all process nodes will be rendered without the state bars (like a normal operation) because they're not introducing any state that would alter the overall application state
AsParent - the shading of the patch background becomes the same as the one from the parent patch effectively visualizing the fact that the state is owned by the parent. Should the parent lifetime be OnStack, the process nodes will be rendered as such as well.
BySink - patch has its own background - this is what we're used to now
Implications
The language gets simplified drastically.
We no longer need to distinguish between stateless and stateful patches. They always consist of a main patch with at least two sub patches (Create & Dispose). Any modifications of the patch model should be trivial because we can always assume the same structure (e.g. Copy & Paste).
No need to split functionality into operations and process just to be able to make use of it inside of a region
...
Implementation
OnStack
using var myState = new MyState();
// ...
ByParent
object state = default;
() =>
{
var myState = state as MyState ?? new MyState(...);
state = myState;
}
BySink
The state needs to be passed explicitly through a object stateInput and out object StateOutput parameters on a delegate. The system generated delegates will recognize that parameter and initialize it accordingly:
(stateInput, ..., out stateOutput) =>
{
var myState = stateInput as MyState ?? new MyState(...);
// ...
stateOutput = myState;
}
The pseudo code for a sink would be:
// OnCreate
this.state = null;
// OnUpdate
function.Invoke(state, ..., out state)
this.state = state;
// OnDispse
(this.state as IDisposable)?.Dispose()
The text was updated successfully, but these errors were encountered:
Addressing quest #44
This proposal is not yet completely finished. Consider it WIP!
Summary
This proposal introduces three lifetimes which can be applied on a region level. They define how long a process inside of such a region is alive.
The three lifetimes are
OnStack
- a process will live only on the stackIt is completely thread safe and can always be offered, the restriction of process nodes not being allowed in stateless contexts can therefor be lifted entirely (same applies for pads).
AsParent
- the lifetime of a process is tied to the containing patchIt is also always available. However there are some details to clarify what should happen if parent is set to
OnStack
and the delegate we're in doesn't get invoked immediately.BySink
- the lifetime is controlled by the sinkIt is thread safe as well. However it is only available if the state gets passed explicitly by the caller. See below for details.
Visualization
In order to reason about a patch we need to be able to see what lifetime currently applies.
OnStack
- all process nodes will be rendered without the state bars (like a normal operation) because they're not introducing any state that would alter the overall application stateAsParent
- the shading of the patch background becomes the same as the one from the parent patch effectively visualizing the fact that the state is owned by the parent. Should the parent lifetime beOnStack
, the process nodes will be rendered as such as well.BySink
- patch has its own background - this is what we're used to nowImplications
The language gets simplified drastically.
Create
&Dispose
). Any modifications of the patch model should be trivial because we can always assume the same structure (e.g. Copy & Paste).Implementation
OnStack
ByParent
BySink
The state needs to be passed explicitly through a
object stateInput
andout object StateOutput
parameters on a delegate. The system generated delegates will recognize that parameter and initialize it accordingly:The pseudo code for a sink would be:
The text was updated successfully, but these errors were encountered: