Re: [jdt-dev] Eclipse Refactoring Question

[Markus Keller <markus_keller@xxxxxxxxxx>]

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 <softwarengineer2004@xxxxxxxxx>
Sent by: jdt-dev-bounces@xxxxxxxxxxx

2005-11-08 03:00

Please respond to
"Eclipse JDT general developers list." <jdt-dev@xxxxxxxxxxx>

To	jdt-dev@xxxxxxxxxxx
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
jdt-dev@xxxxxxxxxxx
https://dev.eclipse.org/mailman/listinfo/jdt-dev