Migrate type hierarchy to use Rubydex#4072
Open
vinistock wants to merge 1 commit intorubydex_adoption_feature_branchfrom
Open
Migrate type hierarchy to use Rubydex#4072vinistock wants to merge 1 commit intorubydex_adoption_feature_branchfrom
vinistock wants to merge 1 commit intorubydex_adoption_feature_branchfrom
Conversation
19 tasks
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.
Motivation
This PR migrates type hierarchy to use Rubydex.
Implementation
I moved all constant resolution to the prepare type hierarchy request, which pays the price once for resolving and then forwards the fully qualified name to super/sub types through the flexible
dataattribute. I also ensured that users can request singleton hierarchy.The super types request is considerably simpler because the fully qualified name is always received through the
dataattribute.The rest of the implementation ensures that we are handling singleton classes correctly because of their implicit nature. For example:
The
Foo::<Foo>declaration inherits fromObject::<Object>, which exists in the graph, but there's no definition to back it up (it's implicit). In those cases, we need to find the definition of the original attached object, so that we can show something useful to the user.Automated Tests
I added a bunch more tests verifying that we behave correctly under a variety of conditions.