-
Notifications
You must be signed in to change notification settings - Fork 11
Add method table as key for method_info
#140
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
Conversation
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.
This looks great and less intrusive than expected. I don't have any reservations about the implementation.
It probably makes sense to bump CodeTracking's version to 2.0.0 as part of this PR. You could also make it 2.0.0-DEV if you want to signal that other breaking changes should land before release.
Codecov ReportAttention: Patch coverage is
Additional details and impacted files@@ Coverage Diff @@
## master #140 +/- ##
===========================================
- Coverage 89.50% 69.60% -19.90%
===========================================
Files 3 3
Lines 381 408 +27
===========================================
- Hits 341 284 -57
- Misses 40 124 +84 ☔ View full report in Codecov by Sentry. 🚀 New features to boost your workflow:
|
As all other manipulation functions for IdDict don't convert, it's best to be consistent and catch errors when we detect a mismatch.
cb638fa
to
9f354c6
Compare
9f354c6
to
dc208c1
Compare
Is it ok to drop 1.6 and support only from 1.10 onwards? |
Definitely! |
Tests will fail, that's normal
(forgot to squash before merge, I cleaned things up in 8e1ca1e) |
Modify the format of
method_info
to have it keyed bymt::Union{Nothing, MethodTable} => sig
pairs instead ofsig
.This allows Revise and other packages to lookup
method_info
scoped by an external method table, if any (a value ofnothing
representing the internal method table).An alternative design would be use two dictionaries, where the current
sig => [(lnn, ex)...]
mapping would be a value of an outermt => info
mapping. I went with keeping a single dictionary (but modifying its key format) for simplicity, but I am open to other designs.