Repository navigation
Conversation
Expose get_similar_occurrences() so clients can decide whether to offer similar-code extraction without constructing the resulting Change. Reuse the existing validation and match collection, and document the count for API callers. Fixes: #168
Codecov Report✅ All modified and coverable lines are covered by tests. Additional details and impacted files@@ Coverage Diff @@
## master #947 +/- ##
=======================================
Coverage 95.43% 95.44%
=======================================
Files 134 134
Lines 26843 26874 +31
=======================================
+ Hits 25618 25649 +31
Misses 1225 1225 ☔ View full report in Codecov by Harness. 🚀 New features to boost your workflow:
|
| that option. It returns the number of regions similar extraction would | ||
| process, without creating a ``Change``. In the usual case, a result greater | ||
| than one means that similar extraction would affect additional regions. | ||
|
|
There was a problem hiding this comment.
Rather than adding an API that's specific to just extract-similar refactoring, I was actually thinking that this should be more of a general-purpose API to ask the refactoring class to compute a preview object.
An API that could be used, for example, for rename/extract similar operation to preview how many files/occurrences would be affected, listing valid target scopes where extract operation would or could place the extracted method/variable, previewing the function arguments of extract method, how many occurrences would be affected by inline refactoring, how many things organise import would remove/move, etc, without fully calculating the changeset. Integrations could display these info in the UI so users can make more informed decision before performing them, or they could use it to enable/disable actions like similar that doesn't always make sense.
The availability of what info is available is of course going to be specific to each operation, but the API for requesting these preview information objects should have a somewhat consistent contract between different refactoring operations.
I think the implementation here for get_similar_occurrences() looks fine but the API should be left undocumented and considered private for now until we can sketch out the API contract in a separate ticket. I'd approve the PR if we leave out the documentation for now.
Add
get_similar_occurrences()to extract-method and extract-variablerefactorings. It runs the existing validation and match collection and
returns the number of matching regions without constructing a ChangeSet or
applying replacements. This lets editor integrations decide whether to
offer the similar-code option before calculating the full refactoring.
Document the API and test counts for both refactoring types, including a
selection with no other matches.
Tests:
python3 -m pytest -q(2172 passed, 7 skipped, 5 xfailed).Closes #168