Comes with a runtime penalty in all proposed implementations
Again we argue that we need a high-level node-set, which when done right gives the user the possibility to
Visually describe the object graph (via a patch)
But also it is code; allowing to describe the object graph with respect to Live Data.
This combination should be superior to any special UI you could come up with.
But this time we want to get rid of any wrapping. Meaning:
We want process nodes that all manage parts of one living object graph
Getting rid of the idea that there are many descriptions at hand. We only have one mutating object graph.
Object Tree Graphs
In essence, this means that a user patch is always tree-shaped. We don't want to have nodes fighting for the one living thing. And we don't want to have warnings on links all over the place about possibly unwanted mutation. In order to guide the user, there is the possibility to make use of TreeNodeManagers.
The philosophy of this proposal
We only want to have ONE way of building/describing an object graph. We want a node set that statically describes an object graph configuration. The tree shaped description is the thing that matters. Get the data right before feeding it into the inputs of the process nodes describing the object graph. There is only ONE way to do it and therefore there are no surprises when reading such a patch.
In this proposal we clearly distinguish design-time from runtime, which is a good thing.
Design-time is building a patch that describes the object graph. Adding a diffuse or specular material feature to your material is something that you want to do at design-time (changing the configuration of a material is an expensive operation and is not comparable with changing a value within an object graph). The patch reflects the features of your object graph, makes it readable and outlines the general idea.
At runtime there may be Live Data influencing the properties of the object graph.
We don't want to have a nodes yielding ready-made object graphs; If we had those, the user would now want to start from a ready-made/wrapped-away black box and would ask for nodes that adjust the ready-made object graph at runtime. We don't want that as we end up with another way of expression. Readability is in danger. Also, it might come with performance penalties. Again: Suddenly something is happening at runtime, which should have done at design time.
Too tedious to build object graphs?
The user might say: This too tedious. I want a node that builds the object graph for me. I don't want to patch a material from scratch each time.
Answer: We need a way to start from a template and let the user mutate that patch template at design time. This sort of mutation is about replacing one node by another, deleting or adding nodes. By that we end up with a readable patch describing the object graph, which was easy to build, since we were allowed to start from a template.
Implementation
We only need to build process nodes managing the live time of an instance of the original data type(s).
A process node is a short way for managing an instance and setting the properties.
Enabling the State Output allows building the object tree
The process nodes have inputs for all properties. Some of them can be optional. But all of them have to be there in order to get away with those process nodes alone.
There are different strategies when to call the property setter:
A) Always on update
C) Only when the input value has changed (e.g. Cache region around the property setter)
G) Only when the input is unequal to the managed property (requiring to call the property getter)
F) On a node fragment
Think about skipping the low-level node-set. As soon as you also allow the original operations to mutate the managed instance you can run into issues:
C) WYSIWYG might break: Your descriptive patch doesn't reflect the state of the managed object any longer: A down-stream imperative node triggered in the past might have changed the state of the object.
G) You get WYSIWYG, but that might come with a performance penalty depending on the implementation of the original property getter that you now have to execute all the time.
A) and F) are ok regarding WYSIWYG, but might end up calling the setter to often
Summary
In order to sell this pattern - together with the bold claim that there shall be only one way of expression - we need templates to start from. Which is a quest on its own.
A solution for #30
31 is elegant but
Again we argue that we need a high-level node-set, which when done right gives the user the possibility to
This combination should be superior to any special UI you could come up with.
But this time we want to get rid of any wrapping. Meaning:
Object Tree Graphs
In essence, this means that a user patch is always tree-shaped. We don't want to have nodes fighting for the one living thing. And we don't want to have warnings on links all over the place about possibly unwanted mutation. In order to guide the user, there is the possibility to make use of TreeNodeManagers.
The philosophy of this proposal
Too tedious to build object graphs?
The user might say: This too tedious. I want a node that builds the object graph for me. I don't want to patch a material from scratch each time.
Answer: We need a way to start from a template and let the user mutate that patch template at design time. This sort of mutation is about replacing one node by another, deleting or adding nodes. By that we end up with a readable patch describing the object graph, which was easy to build, since we were allowed to start from a template.
Implementation
We only need to build process nodes managing the live time of an instance of the original data type(s).
Summary
In order to sell this pattern - together with the bold claim that there shall be only one way of expression - we need templates to start from. Which is a quest on its own.