-
-
Notifications
You must be signed in to change notification settings - Fork 4
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
Always assign UUID #354
Merged
Merged
Always assign UUID #354
Conversation
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
@ChrisRenfrow Continues to be a small change. |
MikkelPaulson
force-pushed
the
always-assign-uuid
branch
from
August 22, 2024 21:02
d26d24f
to
ddc06f2
Compare
Deploying initiative-sh with Cloudflare Pages
|
MikkelPaulson
force-pushed
the
always-assign-uuid
branch
4 times, most recently
from
September 3, 2024 00:34
ca9456d
to
e5a9f48
Compare
MikkelPaulson
force-pushed
the
always-assign-uuid
branch
2 times, most recently
from
September 4, 2024 15:12
06af757
to
868b34b
Compare
The compiler complains about taking references to static mut. We're only using it ephemerally in tests, so safety isn't a big concern, but avoiding build errors is.
Since a UUID isn't guaranteed valid anyway, there's no point in having a newtype for Npc vs. Place UUIDs, and it just adds an extra layer of From/Into.
We still need a way to represent a blob of data that is not a complete Thing, for the purposes of undo/redo, (re)generating information, etc. This is now done by following the pattern of Thing { uuid, data }, where all meta fields are contained within data. (Parallels of this pattern have also been created specifically for Npc and Place.) To keep this change "small", the `uuid` property of `Thing` remains `Option`al; I'll tighten up the distinction between `Thing` and `ThingData` in a future commit.
MikkelPaulson
force-pushed
the
always-assign-uuid
branch
from
September 4, 2024 15:28
868b34b
to
aa51e6d
Compare
MikkelPaulson
force-pushed
the
always-assign-uuid
branch
4 times, most recently
from
September 9, 2024 15:50
ab1e8f1
to
b15db46
Compare
* Change the type of Thing.uuid, Npc.uuid, and Place.uuid from Option<Uuid> to Uuid * Add an is_saved flag to the above to serve the purpose that the None was previously serving *in certain circumstances* (ie. when the Thing was saved to the recent list rather than the journal) * Rewote the repository layer to operate on a ThingData when creating Things and a UUID in most other cases. The repository is also responsible for issuing UUIDs except in specific circumstances (undo or while importing). * The tests, oh god the tests.
MikkelPaulson
force-pushed
the
always-assign-uuid
branch
from
September 9, 2024 17:19
b15db46
to
196f6a6
Compare
Boolean flag was used to indicate if a Thing was currently located in the journal or temporarily stored in recent entries. This wasn't ideal because the data saved to journal/recent included the flag, so there was a lot of bespoke logic to ensure (maybe unsuccessfully) that the flag was never accidentally saved to the wrong place. Instead, we wrap the Thing in an ephemeral wrapper called Record, making the saved-ness of the Thing accessible through the return value if needed but without bothering to include it in either the stored data or code that interacts with the data directly without regard for where it came from.
Turns out Clippy has Opinions about clean code in tests too!
Replace the into_(place|npc)(_data)? functions with implementations of the TryFrom trait, because that's what it's for.
MikkelPaulson
force-pushed
the
always-assign-uuid
branch
from
September 9, 2024 17:36
196f6a6
to
f49e8a4
Compare
Rust 1.81.0 stabilizes #[expect] annotations, which function like #[allow] but fail in the case that the lint does not occur. This updates all existing uses of #[allow] to either use #[expect], or removes unnecessary lint overrides altogether.
MikkelPaulson
added a commit
that referenced
this pull request
Oct 30, 2024
GitHub action was updated to apply Clippy to tests in #354, but the test.sh script was not updated. This is now fixed.
MikkelPaulson
added a commit
that referenced
this pull request
Oct 31, 2024
GitHub action was updated to apply Clippy to tests in #354, but the test.sh script was not updated. This is now fixed.
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
This is a working change to ensure that the
Thing
object (as well as subtypesNpc
andPlace
) always have UUIDs present whether or not they have been saved to the journal. This is done by moving all data fields fromNpc
andPlace
into substructsNpcData
andPlaceData
, respectively. Then the times when we refer to a lump of data, we can useNpcData
(such as when applying a diff), while when we want to refer to an entire record, we can useNpc
.Ultimately I expect this to have the benefit of clarifying when we're talking about a
Thing
vs. when we're only talking about its data.