-
Notifications
You must be signed in to change notification settings - Fork 7
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Allowing for nodes with "generic" inputs and outputs. #2
Comments
Negative trait bounds or mutually exclusive trait implementations would assist a lot with this. E.g. pub trait IsAdd {
fn is_add(&self) -> bool;
}
impl<T, U> IsAdd for T
where
T: Add<U>,
{
fn is_add(&self) -> {
true
}
}
impl<T, U> IsAdd for T
where
T: !Add<U>,
{
fn is_add(&self) -> {
false
}
} |
mitchmindtree
added a commit
to mitchmindtree/gantz
that referenced
this issue
Mar 24, 2019
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. Closes nannou-org#11 Closes nannou-org#9 Closes nannou-org#7 Closes nannou-org#3 Closes nannou-org#2
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
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: