New implementation of reactive tables. #113
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
Up until now, the values used in a reactive table had to implement a bunch of traits (such as Equality, Orderable etc ...). The reason was that the implementation was relying on a sort of those values to function properly (compute the diffs etc ...). The other weird thing is that the implementation was returning a sorted array of the values inserted and was perform a "unique" operation on them for no good reason other than it was convenient for the old implementation. This new implementation fixes that, the values don't have any constraint other than being frozen (the interned pointer is used to do the operations). The values returned by "get" preserve repetitions. PS: Turns out the new implementation fixed a long standing bug in the incremental type-checker when a module was changing name. PS2: I used the opportunity to also fix issue #72.
facebook-github-bot
added
the
CLA Signed
pikatchu
added a commit
that referenced
this pull request
Nov 22, 2019
* New implementation of reactive tables. Up until now, the values used in a reactive table had to implement a bunch of traits (such as Equality, Orderable etc ...). The reason was that the implementation was relying on a sort of those values to function properly (compute the diffs etc ...). The other weird thing is that the implementation was returning a sorted array of the values inserted and was perform a "unique" operation on them for no good reason other than it was convenient for the old implementation. This new implementation fixes that, the values don't have any constraint other than being frozen (the interned pointer is used to do the operations). The values returned by "get" preserve repetitions. PS: Turns out the new implementation fixed a long standing bug in the incremental type-checker when a module was changing name. PS2: I used the opportunity to also fix issue #72. * removed constraints on Reactive table type parameter * revert changes in skip_to_native
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.
Up until now, the values used in a reactive table had to implement
a bunch of traits (such as Equality, Orderable etc ...).
The reason was that the implementation was relying on a sort of
those values to function properly (compute the diffs etc ...).
The other weird thing is that the implementation was returning
a sorted array of the values inserted and was perform a "unique"
operation on them for no good reason other than it was convenient
for the old implementation.
This new implementation fixes that, the values don't have any constraint
other than being frozen (the interned pointer is used to do the operations).
The values returned by "get" preserve repetitions.
PS: Turns out the new implementation fixed a long standing bug in the
incremental type-checker when a module was changing name.
PS2: I used the opportunity to also fix issue #72.