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

A nicer API for graph state #44

Open
mitchmindtree opened this issue Jul 26, 2019 · 0 comments
Open

A nicer API for graph state #44

mitchmindtree opened this issue Jul 26, 2019 · 0 comments

Comments

@mitchmindtree
Copy link
Member

Currently, gantz uses a very ad-hoc approach of passing slices of Any trait objects into the evaluation functions in order to provide access to state for nodes and nested graphs. There are two major issues with this approach:

  1. Recently it was discovered that the Any trait becomes unusable for this approach once non-std types are involved (see std::any::TypeId returns different results for the same non-std type in different binaries. Switch to something else for feeding state through nested graphs. #43). We can work around this by simply using *mut () instead and casting them to the expected type internally, but this is obviously highly unsafe and would easily lead to a lot of errors with the current, awkward slice-passing approach.
  2. The approach of passing slices of references to state is awkward and could easily lead to borrow-checker issues in cases where the user is trying to retrieve multiple mutable references from the same state-storing data structure. The unsafety of switching to raw pointers would be amplified by the awkwardness of the API and make it even more likely to trigger UB accidentally.

It would be nice to come up with some kind of type-safe abstraction that could solve both of these issues. This will likely have to wrap a raw pointer at the boundary, but at least if these raw pointers could be created and downcasted behind some safer API there would be less chance of any issues.

Here are some goals of what should be possible with node state:

  • Easy to read and write to node state within application code (outside of graph evaluation). This is necessary to allow for custom serialization approaches, to allow for GUI to reflect the state of nodes within the graph and to pass the results of graph evaluation to and from I/O where necessary. This seems to imply that the user should likely own all state within the application process code itself and only references when necessary to the graph evaluation process.
  • Easy to pass mutable access of node state to the graph for graph evaluation. We want to avoid borrow-checker awkwardness and unsafety as mentioned above.
  • Application state should be accessible when creating new nodes and in turn new node states. This probably rules out having the graph just own all the state and using something like Default to initialize new instances. That said, it might be possible to provide some trait or something that allows for application state to be accessible when creating new node instances.

Potential Solution

Perhaps one solution might be to create a data structure in which the user is expected to store all state. Maybe this could be a kind of rose tree constructed using Vecs whose ordering precisely matches the node ordering within the gantz graph? We would need to ensure that this data structure and the graph itself are always updated together in order to be able to guarantee that their indices match and can be relied upon when retrieving references for graph evaluation. It's not yet clear to me whether or not the graph should own this state or the application should. In a way, the application will own the graph state either way as it also owns the graph, but the indirection may get frustrating from a usability point of view.

mitchmindtree added a commit to mitchmindtree/gantz that referenced this issue Jul 26, 2019
This is a quick hack to get the nested graph working as a proof of
concept. The test successfully calls the root graph which in turn calls
into the inner nested graph to produce the correct result for the
following assertion. nannou-org#44 should be addressed next.

Closes nannou-org#20.
mitchmindtree added a commit to mitchmindtree/gantz that referenced this issue Jul 26, 2019
This is a quick hack to get the nested graph working as a proof of
concept. The test successfully calls the root graph which in turn calls
into the inner nested graph to produce the correct result for the
following assertion. nannou-org#44 should be addressed next.

Closes nannou-org#20.
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