Skip to content
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

Closed
mitchmindtree opened this issue Oct 18, 2018 · 1 comment
Closed

Allowing for nodes with "generic" inputs and outputs. #2

mitchmindtree opened this issue Oct 18, 2018 · 1 comment

Comments

@mitchmindtree
Copy link
Member

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).

@mitchmindtree
Copy link
Member Author

mitchmindtree commented Oct 18, 2018

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:

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
Labels
None yet
Projects
None yet
Development

No branches or pull requests

1 participant