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
One issue with implementing nodes in gantz at present is that input and output types to a node must be "solid" types. As a result, implementing something even as simple as Add can be quite painful, as there would need to be an AddF32, AddF64, AddI32, etc just to be able to support all the possible kinds of addition. Even then, nodes would be missing for all custom implementations of Add.
Ideally, there would be some way of allowing nodes to take "generic" input and output types, as long as those types satisfy some trait bound that describes the node's behaviour. Unfortunately this isn't as simple as it sounds.
Downcasting to Trait implementations (trait objects)
Currently rust only provides the ability to downcast from types implementing Any to other solid types, but not to trait implementations. This is an issue for the node as we want to avoid knowing exactly what the type is - we just want to know that it can behave in the way that we expect (addition in our case). Things get more complicated when we take into account the fact that not only the individual type matters, but the other input and output types also matter. E.g. a single type can have multiple Add implementations based on the right-hand side argument, and each of these implementations may imply different Output types as well. Thus, simple "trait downcasting" cannot be the whole answer.
More likely, we can use some combination of some higher-level custom trait and a blanket implementation for all types implementing the trait we actually care about (perhaps with some wrapper type to help).
The text was updated successfully, but these errors were encountered:
Negative trait bounds or mutually exclusive trait implementations would assist a lot with this. E.g. Add could be implemented for the general Node type and allow for checking for the implementation via:
This updates the project code to add a `dylib` target and implements
compilation of gantz nodes when added to the project and when updated.
The example has been updated to demonstrate graph manipulation
and execution of the resulting `dylib` all at runtime.
Closesnannou-org#11Closesnannou-org#9Closesnannou-org#7Closesnannou-org#3Closesnannou-org#2
One issue with implementing nodes in gantz at present is that
input
andoutput
types to a node must be "solid" types. As a result, implementing something even as simple asAdd
can be quite painful, as there would need to be anAddF32
,AddF64
,AddI32
, etc just to be able to support all the possible kinds of addition. Even then, nodes would be missing for all custom implementations ofAdd
.Ideally, there would be some way of allowing nodes to take "generic" input and output types, as long as those types satisfy some trait bound that describes the node's behaviour. Unfortunately this isn't as simple as it sounds.
Downcasting to
Trait
implementations (trait objects)Currently rust only provides the ability to downcast from types implementing
Any
to other solid types, but not to trait implementations. This is an issue for the node as we want to avoid knowing exactly what the type is - we just want to know that it can behave in the way that we expect (addition in our case). Things get more complicated when we take into account the fact that not only the individual type matters, but the other input and output types also matter. E.g. a single type can have multipleAdd
implementations based on the right-hand side argument, and each of these implementations may imply differentOutput
types as well. Thus, simple "trait downcasting" cannot be the whole answer.More likely, we can use some combination of some higher-level custom trait and a blanket implementation for all types implementing the trait we actually care about (perhaps with some wrapper type to help).
The text was updated successfully, but these errors were encountered: