Eclipse Refactoring Question

classic Classic list List threaded Threaded
2 messages Options
Reply | Threaded
Open this post in threaded view
|

Eclipse Refactoring Question

Irum Godil
Hi,
 
I want to know that what are the underlying assumptions based on which the Eclipse Refactoring determines if a certain refactoring (specifically for Extract Method) is correct/possible or not. For instance, in some cases the tool allows you to extract statements into a method and in some cases it does not.
 
So on what theoretical basis is this based? i.e. how did the designers of the refactoring plugin know when they want to allow refactoring and when not? I am asking this question, as I am considering the theoretical basis for Aspect-Oriented Refactoring; and I am not sure what rules would apply that would tell me if a specific fragment can/cannot be refactored.
 
I will really appreciate your response and/or any pointers to documentation outlining these decisions.
 


Thanks a lot,
Sincerely,
Irum Godil.
 


Yahoo! FareChase - Search multiple travel sites in one click.
_______________________________________________
jdt-dev mailing list
[hidden email]
https://dev.eclipse.org/mailman/listinfo/jdt-dev
Reply | Threaded
Open this post in threaded view
|

Re: Eclipse Refactoring Question

Markus Keller

Hi Irum

In general, Eclipse refactorings are allowed as soon as we can do "something reasonable". Usually, that means that a refactoring is available when we have an AST with bindings for the affected code range. When we can guarantee (by informal reasoning with JLS3 and supported by test cases) that the refactoring does not change the semantics of the program, then the refactoring passes without warnings. If we cannot be sure (e.g. because of missing bindings), an error is raised, but the user can still proceed.

Preserving the semantics of a program usually means that the program behaves exactly the same as before the refactoring (i.e. a client running the program would not notice any difference). Reflection is usually not considered in this analysis, since that would make most refactorings impossible. Otherwise, the Java language is pretty well-behaved in the sense that local reasoning is usually enough to get a long way (e.g. Extract Method only affects  the extracted code range and the enclosing method, and if the extracted method does not take part in an overriding relationship with an existing method, then the refactoring does not affect further code).

Ideas on things to consider to avoid semantic shifts can be found in various books and websites on refactoring, including the "original" book: http://martinfowler.com/books.html#refactoring

Cheers,
Markus




Irum Godil <[hidden email]>
Sent by: [hidden email]

2005-11-08 03:00

Please respond to
"Eclipse JDT general developers list." <[hidden email]>

To
[hidden email]
cc
Subject
[jdt-dev] Eclipse Refactoring Question





Hi,
 
I want to know that what are the underlying assumptions based on which the Eclipse Refactoring determines if a certain refactoring (specifically for Extract Method) is correct/possible or not. For instance, in some cases the tool allows you to extract statements into a method and in some cases it does not.
 
So on what theoretical basis is this based? i.e. how did the designers of the refactoring plugin know when they want to allow refactoring and when not? I am asking this question, as I am considering the theoretical basis for Aspect-Oriented Refactoring; and I am not sure what rules would apply that would tell me if a specific fragment can/cannot be refactored.
 
I will really appreciate your response and/or any pointers to documentation outlining these decisions.
 


Thanks a lot,
Sincerely,
Irum Godil.

www.cs.utoronto.ca/~irum
 


Yahoo! FareChase - Search multiple travel sites in one click. _______________________________________________
jdt-dev mailing list
[hidden email]
https://dev.eclipse.org/mailman/listinfo/jdt-dev


_______________________________________________
jdt-dev mailing list
[hidden email]
https://dev.eclipse.org/mailman/listinfo/jdt-dev