When it comes to idea of conversion (modification) of Gbx, node mutability is most often used to simplify the work.
However, this mutation persists in the stored GbxModel, creating an unnatural behavior of outputting mutated Gbx, while the inputted Gbx was also modified.
Potential fix: Deeply clone input parameters by default, and optionally suppress this behavior with [ImmutableParameter] provided by the developer (to increase performance). Known fully immutable types shouldn't require this parameter.
Outside of Produce and Proceed, there could be also an option for Modify which would adjust the UI better to the user knows the Gbx was modified in place.
It is also possible to solve temporarily by using the Gbx memory stream to parse it on individual tool instance. GBX.NET node cloning would be much preferable option though.
When it comes to idea of conversion (modification) of Gbx, node mutability is most often used to simplify the work.
However, this mutation persists in the stored GbxModel, creating an unnatural behavior of outputting mutated Gbx, while the inputted Gbx was also modified.
Potential fix: Deeply clone input parameters by default, and optionally suppress this behavior with
[ImmutableParameter]
provided by the developer (to increase performance). Known fully immutable types shouldn't require this parameter.Outside of Produce and Proceed, there could be also an option for Modify which would adjust the UI better to the user knows the Gbx was modified in place.