Use MultiMap for RojoRef -> Ref tracking #4
Merged
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
kennethloeffler
commented
Feb 6, 2024
Comment on lines
+366
to
+367
| let duped = tree.insert_instance(tree.get_root_id(), snapshot.clone()); | ||
| assert_eq!(tree.get_specified_id(&custom_ref.clone()), None); |
There was a problem hiding this comment.
Is this the behavior we want? RojoTree::get_specified_id could just pull out the first element of the multimap entry and return it in the duplicates case, instead of None... not sure if it really matters, tbh
There was a problem hiding this comment.
I think it's probably fine. We don't really care too much about the behavior as long as we handle it and emit a message for the user since it's a logic bug on their end.
Dekkonot
approved these changes
Feb 6, 2024
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.
In rojo-rbx#843, there was some hairiness around the semantics of duplicate RojoRefs. The problems basically boil down to limitations of
HashMap<RojoRef, Ref>. Creating a duplicate could clobber the original mapping. Removing a duplicate could also either clobber the original mapping, or else fail to update the mapping. I think to get this right,we have to make a slight change to the design.This PR changes
RojoTree.specified_ids_to_refstoMultiMap<RojoRef, Ref>so that Rojo will always do the right thing when it encounters duplicates. This encodes the possibility of duplicates into the data model, simplifying the code.RojoTree::get_specified_idwill still reduce all possibilities into a single-valued option, so the overall behavior should stay the same.