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
We should have an off-by-default feature called "async" which makes all of the turtle methods return Future<...> types instead of nothing. This would require a complete restructuring and is probably a great thing to do with #16 since that requires significant refactoring too. When the feature is off, the methods would call the async code and then run wait() at the end instead of returning the future. Though each method returns immediately, the animations are queued up within each turtle and played sequentially. The futures return when their respective animations complete. Getters for the various properties return the current value immediately and do not represent any specific state after a given animation.
Animations can still be controlled and coordinated by chaining and composing different futures, perhaps with async/await syntax.
This would enable a huge range of really interesting and complex use cases--great for advanced lessons! That being said, it's important that the library in its default state remains extremely simple and usable.
A large portion of the work for this issue was completed in #173. There is now an AsyncTurtle struct and an AsyncDrawing struct for interacting with the crate asynchronously. We're still working out the API and there are no docs yet, so neither of those types has been made public.
If you'd like to try them out, you can do so by creating a local copy of the crate and manually marking those structs pub yourself. This is still largely experimental and there are many bugs/performance issues that need to be worked out. Feel free to experiment and report back what you find!
We should have an off-by-default feature called "async" which makes all of the turtle methods return
Future<...>
types instead of nothing. This would require a complete restructuring and is probably a great thing to do with #16 since that requires significant refactoring too. When the feature is off, the methods would call the async code and then runwait()
at the end instead of returning the future. Though each method returns immediately, the animations are queued up within each turtle and played sequentially. The futures return when their respective animations complete. Getters for the various properties return the current value immediately and do not represent any specific state after a given animation.Animations can still be controlled and coordinated by chaining and composing different futures, perhaps with async/await syntax.
This would enable a huge range of really interesting and complex use cases--great for advanced lessons! That being said, it's important that the library in its default state remains extremely simple and usable.
The text was updated successfully, but these errors were encountered: