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
Hi guys! Move, as implemented in Sui, is an interesting language to build upon, even outside of context of Sui - in my case, I would like to experiment with p2p digital board games driven by a contract language. Playing with the code a little bit, it seems like your fork should still have enough decoupling between core Move language and "Sui mode" features in the compiler to make it easy enough to add support for custom flavors. move_package_alt is a good example of that, as it seems to handle flavors through trait-based interface, instead of wiring them in.
I do understand that this is not a priority for fast-moving team, but would like to ask whether PRs attempting to put cleaner separation between Move compiler and "Sui mode" would be welcome, to allow creation of custom flavors with the codebase used as a dependency instead of a fork. There are of course alternativeimplementations based on Move codebase, but any fork attempting to rewire internal infrastructure downstream seems to be destined to start diverging from upstream, making it harder to access new language features and fixes.
reacted with thumbs up emoji reacted with thumbs down emoji reacted with laugh emoji reacted with hooray emoji reacted with confused emoji reacted with heart emoji reacted with rocket emoji reacted with eyes emoji
Uh oh!
There was an error while loading. Please reload this page.
-
Hi guys! Move, as implemented in Sui, is an interesting language to build upon, even outside of context of Sui - in my case, I would like to experiment with p2p digital board games driven by a contract language. Playing with the code a little bit, it seems like your fork should still have enough decoupling between core Move language and "Sui mode" features in the compiler to make it easy enough to add support for custom flavors.
move_package_altis a good example of that, as it seems to handle flavors through trait-based interface, instead of wiring them in.I do understand that this is not a priority for fast-moving team, but would like to ask whether PRs attempting to put cleaner separation between Move compiler and "Sui mode" would be welcome, to allow creation of custom flavors with the codebase used as a dependency instead of a fork. There are of course alternative implementations based on Move codebase, but any fork attempting to rewire internal infrastructure downstream seems to be destined to start diverging from upstream, making it harder to access new language features and fixes.
Beta Was this translation helpful? Give feedback.
All reactions