Repository navigation
Conversation
Codecov Report✅ All modified and coverable lines are covered by tests. Additional details and impacted files@@ Coverage Diff @@
## master #947 +/- ##
=======================================
Coverage 95.44% 95.45%
=======================================
Files 134 134
Lines 26910 26941 +31
=======================================
+ Hits 25685 25716 +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.
There was a problem hiding this comment.
Thanks, I agree that a consistent preview API could be useful if and when other refactorings need it. For this change, the concrete need is to let integrations decide whether the similar-extraction action is meaningful. I do not think we need a general preview architecture now; designing one would be a separate PR. I have kept this method documented and clarified that its count includes the selected region.
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
517c871 to
1da5b64
Compare
Clarify that the count includes the selected region and explain how integrations can use it to decide whether to offer similar extraction without building or applying a ChangeSet.
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