• The real contribution of the paper is not in applying useful refactorings (admittedly, this has been done before), but in providing a robust framework based on type constraints capable of proving refactorings safe for any source program.
• I was a little surprised by the presentation's use of the 'Bad' ('unrefactorable') predicate to define the solution. I was expecting them to find a fixpoint solution to the constraint equations that maximized the type of the type unknowns that are to be refactored. It seems simpler and just as good.
• For me, the main weakness of the paper is that I didn't come away understanding why this work is useful. Is there empirical evidence that best-practices development techniques lead to programs in need of so much refactoring that automated techniques pay off? Even if the answer is "yes," I'd be tempted to blame this on the use of OO design in domains where it just doesn't work well.
• These techniques could probably also be used to enforce good coding style. One could ask that there be no chain of inter-related constraints above a certain length. It seems like this might correlate with program complexity, and avoiding large constraint systems could help keep programs understandable by people who didn't write them.
• I want a way of combining refactorings. As the paper points out, performing one refactoring A may enable refactoring B. Therefore, it would be best to solve refactoring B in a way that incorporates refactoring A. Can this be done systematically in this framework, or in a fixpoint one as I suggested above? Then, given a set of refactorings and a way of combining them, I want goal-oriented refactoring so that a user can specify a change to be made in one place, and the IDE would suggest a sequence of refactorings to reach the goal.
• First, one should work out the complexity of the algorithm and/or experiments validating the practicality of the algorithm. Also, one should pursue some user studies to see effective the refactoring is for developers.
• One flaw in the work seems to me to lie in their proof methodology. With the caveat that I don't have much experience in reading PL related proofs, these seemed rather ad-hoc to me. In several instances, they make claims such as "three cases exist" and then go on to show the proof for those cases, with no justification to ensure that the taxonomy is correct.
• The analysis for extract interface seems to only consider the case where an interface has no supertypes is implemented by only one class. This is the less common case and I’m not sure if it’s simple to extend the authors’ analysis to handle the more general case of multiple subclasses. The pull up members analysis rules are also stated to be imprecise and although sufficient, may produce false negatives even when it’s possible to refactor.
• My initial impression is that there is too much manual work (proofs, invariance finding, constraint partitioning) for every refactoring that we wish to implement, but this may not be so bad in practice given that #programs >> #refactorings. ... The way refactorings are specified in the paper seemed ad-hoc. For Extract Interface, the refactoring was expressed as a recursive equation, and for Pull Up Members -- something similar to first order logic. Also, the implementation section says nothing about how the system is actually implemented.
• My main concern with this paper is its lack of measurements of the effectiveness of the algorithm. Although I believe it probably works well, it would be nice to have some sort of user study. The authors could have instrumented Eclipse to track refactorings performed by users in the course of development, and to ask the user if he was happy with the result. Particularly with complex type inference algorithms like this one, it's quite possible for the analysis to generate overly conservative results. In this case, it might simply forbid any changes to the code

• What I do not like about the paper is that there is no indication about the efficiency of their algorithm either empirically or theoretically.
• The authors briefly mention that constraints for refactorings and typechecking constraints don't match exactly. It is not immediately obvious why that is.
• I am still unsure of what the relationship is between the constraints discovered in P and P' (it appears P' is a superset).