enum architecture requiring the use of cloning #2
Labels
No milestone
No project
No assignees
2 participants
Notifications
Due date
No due date set.
Dependencies
No dependencies set.
Reference: atiran/txtris#2
Loading…
Reference in a new issue
No description provided.
Delete branch "%!s()"
Deleting a branch is permanent. Although the deleted branch may continue to exist for a short time before it actually gets removed, it CANNOT be undone in most cases. Continue?
Though I'm not exactly sure if it could be done better, the way the architecture has been implemented (#1) means that instead of using more efficient mutable references to update the application state, a new application state (or portions of it) is created every time a modification is required.
So, though the architecture simplifies the codebase, it's also less efficient, which I'd like to avoid if possible.
I've reversed the merge for now, but if this issue can be resolved I'll look into a relevant PR.
damnit now i gotta learn how to fix all the mutability stuff
performance: enum architecture requiring the use of cloningto enum architecture requiring the use of cloningResolved with #3