[Issue] Operator auto generation determinism
For now Operators are identified with a Guid (in the namespace)
First this could be changed by moving to an attribute as per :
[Operator("F65AD97B-F462-4E76-8CDF-B77D992AF580")] public class AddVecTest : Instance<AddVecTest>
This would save namespace parsing (and replace from _ to -)
Slots are also identified by Guid :
[Output(Guid = "2CA0473D-0B36-4CA2-B532-9186E4556D67")] public readonly Slot<float> Result = new();
Issue with this is that auto generating operators on the fly will not be able to provide the same IDs from one build to another. Which will make operators/connections to appear as invalid.
One way would be to store things (like operator name -> id and slot name -> id) into a json file, so when we generate that operator again we reuse the id if name is the same.
Other way is to move to plain strings for operator name (system name, can be assemblyname.classnamespace.classname, which will be unique in a single appdomain).
For Slots, since they also depend on the parent operator (so 2 identical id from a different operator is already allowed), using the slot variable name as Key (or use a key attribute), should also work, since it's hardly common in a user interface that we want to name 2 parameters from the same object with the same value (it's also easy to detect collision and throw an error message).
Use cases :
- Reflect C# library and auto gen operator for methods.
- Reflect Shaders and build correct bindings automatically.
I have been thinking about this proposal for a while now. At the moment I believe that the GUID-namespace works well and with the nested namespace folders now allows identical class names within different namespaces out of the box.
I'm also vary of the implications regarding backwards compatibility and migration. Wouldn't it be possible to have both? Reflection and GUI-Namespaces?