Re: [jdt-ui-dev] Refactoring: checking compilation of multiple compilati

[Adam Kiezun <adam.kiezun@xxxxxxx>]

Hi Robert,

1. the reason is that it's far easier to check that than check every single
precondition that can make the code not compile (and it's a sanity check too)

For example, if you add a temp to a method, its name may not conflict with
any other existing temp. compiler knows precisely when two temps have
conflicting names - so we delegate the job to it, rather than collecting all temps
and doing it ourselves

some refactoring actions do introduce compile errors and it's ok - for
example, when you add a method parameter and specify something as a default value,
we don't parse it to try to figure out if it makes sense or not. 

other examples include moving or inlining methods that access members not
visible from the destination - again, there's many visibility rules, all known
to the compiler, so we let the compile errors happen in those cases.

that's why you have the undo. 
and that's why people should run their tests after performing these actions.

2. no, i cannot think now of any obvious way to tell the compiler that the
given set of working copies should be looked at before the saved compilation
units when getProblems() is called
(maybe there's someting though - if i come up with an answer i will tell
you)

hope this helps a bit
a.

-- 
+++ GMX - Mail, Messaging & more  http://www.gmx.net +++
Bitte lächeln! Fotogalerie online mit GMX ohne eigene Homepage!