-
-
Notifications
You must be signed in to change notification settings - Fork 71
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
SubModelSeq update logic now more functional #241
Conversation
3ff5994
to
5fdbdc9
Compare
5fdbdc9
to
1ea4d1f
Compare
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Wasn't able to look at everything, will continue another time. Feel free to work on the current suggestions, though.
47274b0
to
0c05717
Compare
04c74fb
to
b1bc3a2
Compare
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
More or less good to go. Just a few things left.
I'm happy with this. Feel free to merge. Thanks for your work! |
f2e76a8
to
41e2207
Compare
I locally squashed and rebased onto |
This PR only changes code in the
SubModelSeq
sample.At a high level, the changes are to use more higher-order functions in order to be both more succinct and have more reusable code.
My intention is for the behavior to be unchanged. I also expect the performance to be the same. These changes are not trying to address #236.
I tested this, and I think everything still works the same.
@ScottHutchinson, I think you will be interested in these changes since you are using a
SubModelSeq
binding.