Decouple serialization/deserialization logic from internal data representation #102
Conversation
This file contains hidden or 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
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.
The way rmp_serde reads the Messagepack protocol structure (it only reads as far as needed to fill the struct, even if that's in the middle of a top-level list) means that the serialized version of
Blockerwould not be able to gain any new fields, which is problematic for #97 (which broke forwards-compatibility).I've abstracted out serialization and deserialization logic into a module separate from
BlockerandCosmeticFilterCache. My past decision to break theCosmeticFilterCacheinto a completely different serialization pass makes this a little uglier, but the extra layer of separation between the data format and internal representation makes future changes in both much easier.The extra layer of translation is also very cheap performance-wise, considering that references are used for serialization and structures built up during deserialization can be moved directly into the engine.
I've verified that backwards and forwards compatibility is maintained with DAT files from this branch and be0ba3b.