Ability to work with generic types in ProtoFlux.

[JackTheFoxOtter]

Is your feature request related to a problem? Please describe.

This is a thing I've come across a couple of times now, and I think it would be a nice addition to ProtoFlux to simplify / generalize some setups. Note that I'm not quite sure how a solution to this could look like, but I do want to explain the problem with an example:

I'm writing a piece of code that operates on an IField<T> input object. After the operation, it is supposed to write the IField<T> into a dynamic variable. The problem I'm having is that I presently don't have the ability to write this code in a generic way. I can treat the input object as an IField reference by casting the input type (ex: IField<string> -> IField), but that's where the generalization options end. Currently to call WriteDynamicObjectVariable<T>, I need to choose a type when spawning the node. (So for example WriteDynamicObjectVariable<IField<string>>). This means that I now need to check my input type, figure out what generic type it corresponds to, and call the correct WriteDynamicObjectVariable<T> node for that type, instead of being able to write the code in a generic way. This requires me to hard-code in what types my code support, which is pretty ugly and laborous.

Describe the solution you'd like

I'd like to be able to work with generic types in ProtoFlux. I want to be able to write code that calls a generic node in a generic way.

Describe alternatives you've considered

Hard-coding in supported types, but as pointed out, this is pretty limiting.

Additional Context

No response

Requesters

No response

[Nytra]

You can get this to some degree by using the Box and Unbox nodes, then checking the Type of the object

[JackTheFoxOtter]

Boxing / unboxing doesn't change anything here. You cannot use generic nodes without specifying an explicit type to use presently.

[JackTheFoxOtter]

There's another use-case for this. Once we get nested nodes (#564), it would be extremely useful to be able to specify our own custom generic nodes, for example math operations that work on all number types. Otherwise you'd be required to create multiple versions of the same node for multiple number types, which would quickly become a lot of work, especially if you need to then make a change to them.

[Nytra]

Boxing / unboxing doesn't change anything here. You cannot use generic nodes without specifying an explicit type to use presently.

You can use DynamicImpulseTriggerWithObject<object> and then determine what to do by checking the type

[JackTheFoxOtter]

That is functionally identical to casting the input to IField in my example. It doesn't change the fact that I then would have to check the type and multiplex the flow to multiple different generic nodes, like WriteDynamicObjectVariable<string>, WriteDynamicObjectVariable<float>, ...

[JackTheFoxOtter]

That is functionally identical to casting the input to IField in my example. It doesn't change the fact that I then would have to check the type and multiplex the flow to multiple different generic nodes, like WriteDynamicObjectVariable<string>, WriteDynamicObjectVariable<float>, ...

To add even more context, this is how I currently have to write the code for my use-case:

I would like to be able to treat the input type (in this case my IField) as a generic IField<T> type and just directly call WriteDynamicObjectVariable<T> without specifying that <T> in code. So regardless of whether my input is an IField<string>, IField<float> or IField<Chirality>, the code would work generally without needing to write out explicit handling for all of those types.