Purity Logic

[tugbamtn]

Hi,
I need to check if a class with refactoring has only refactoring, so I asked this question and Mr.Tsantalis directed me to your fork of refactoring-miner. I investigated test cases a little bit but couldn't get quite sure about usage. Normally I use miner.detectAll method and implement public void handle(String commitId, List refactorings) method. So I was expecting something like Refactoring dto object will have boolean isPure attribute.

But from the test cases only method i see is detectModelDiff which takes commit id as argument and I need to implement processModelDiff to visit the umlmodeldiffs and i should call below statement:
Map<Refactoring, PurityCheckResult> pcr = PurityChecker.isPure(umlModelDiff);
does this pcr map returns all the refactorings or it expects this commit to has only refactoring?

I am not quite sure if it is possible but I was expecting refactorings related class has only refactorings so that I can filter out other code changes which might affect software metrics...

[pedramnoori]

Hello,

In order to use PurityChecker, there is a file named API.java. (src/purity/API.java) Within the main method of the API class, you will pass the commit link, and you will get the pcr object from the isPureAPI method. I have used detectModelDiff and overridden the processModelDiff method.

The pcr map returns all the refactorings in the commit as its keys, along with a PurityCheckResult object as its values. The value might be null in cases where we do not support the specific refactoring type purity.

Just do not forget to uncomment some lines in the PurityChecker.java (src/purity/PurityChecker.java) file, so that you can analyze the purity of a specific refactoring type.

For example, if you need to review the purity of an Extract Method refactoring, uncomment the line 47 in the PurityChecker.java file. I commented them because of the testing purposes. Sorry for the inconvenience.

If you need further assistant setting up the tool, please let me know.

[tugbamtn]

Hi,
thank you for the answers. I managed to make it work, also uncommented purity check for all available type. Hovewer I still have a few questions about the definition of Purity. But let me
start by explaining what I am trying to do. Actually I am investigating effects of refactoring
on CK metrics. I wrote a program which utilizes refactoring miner and understand tool in order to extract refactorings and their affects on CK metrics. Normally I was expecting refactorings to decrease CK metrics values however what I seen that the values increased. So that made me think that other modifications in a refactored classes (such as adding new lines of code, changing existing lines, bugfixing etc.) might also affect CK metrics. So I thought I should eveluate commits of classes with only refactorings and no other changes. So from the definition of "Purity" what I understand is the class has only refactoring and no other changes. So my questions are:

1. Is this the same for your Purity definition or is it something else?
2. Currently your fork only checks purity of 8 kinds of refactorings. What is the reason of this? Is it because those 8 kind of refactoring types are the only significant refactoring types? Or it is not easy to implement the rest of refactorings types?

Thank you for your answers.

[pedramnoori]

That is a very interesting topic.

About your questions:

1- Yes. We defined a pure refactoring is the one that does not include any modifications that alter the behavior of the refactored code. It supports changes stemming from specific refactoring type mechanics, overlapping refactoring, etc. In other words, compare to a Root-canal refactoring, we allow a broader range of changes to consider a refactoring as behavior-preserving.

2- PurityChecker only supports method-level refactoring. Extract Method, Extract and Move Method, Inline Method, Move and Inline Method, Move Method, Move and Rename Method, Pull Up Method, and Push Down Method. The reason behind this is that the concept of purity can be well-defined for a refactoring that has a body. We figured that determining purity rules for refactorings that do not have a body would not be beneficial in our research, as in almost all the cases, an Extract Class refactoring for instance, would follow numerous changes within its scope.

Moreover, statement mappings and replacements (bodyMapper) provided from RefactoringMiner, are reported only for method-level refactorings. So, as PurityChecker analyzes these resources for decision-making, we could not extend our tool to support other refactoring types.

We have identified that extending PurityChecker to support other refactoring types can be one of our future works, which can be conducted in future researches.

Let me know if you need further clarification on the tool.
Good luck with your research.

[tugbamtn]

Hi,
Do you think it will be easy to implement if a class in a specific commit only has refactoring changes? Those refactoring changes might not be pure. But for example class has one extract method refactoring or might have more than one refactoring changes together. But it shouldn't have a new method, a new variable declaration or new code line additions which are not related with refactoring.

Thank you for your answers.

[pedramnoori]

Hello,

Currently, neither RefactoringMiner nor PurityChecker do not have this feature to indicate whether a specific commit has only refactoring-related changes. It shouldn't be a super complex feature, but it's more related to the RefactoringMiner (main tool), not PurityChecker.