[
Date Prev][
Date Next][
Thread Prev][
Thread Next][
Date Index][
Thread Index]
[
List Home]
AW: AW: [jdt-ui-dev] Extract Method Refactoring
|
<Hi Jens,
one that has higher proiority is to finish Self Encapsulate Field ;-))>
yes, that`s of course primary
<Although with your contribution it now handles more cases, there are still
open issues:
- compound assignments>
the proposal setField(getField() + expr) for field += expr is ok ?
<- all the cases currently rejected in AccessAnalyzer.checkParent(). One
simple soultion is to return the value from the setter method. But I think
that in 90% of the cases
this isn't needed. So we should only return it if needed. We should use
the same strategy for inc and dec methods too.>
?
<- the UI needs some fields for the inc and dec method names.>
yes, I wrote that I will add them
<- the inc and dec method generate code with this.field. This is not
necessary and isn't normal Java style.>
ok, just a copy and paste error (taken it from generate setter)
<- test cases. Here you have to wait until the test cases are also open
source. But I think this will happen in the next days.>
good
<I also comment on your code. See the attachment.>
thanx
yes, you are right: I didn't know a decent name(s) for inc and dec
so some names are not quite right or good, I will correct them
and the similar methods come from the old approach, this will be
changed
sorry about that...
a new patch is enclosed
I am not sure about the handlePrefixExpression/handlePostfixExpression
methods... should I combine them ?
<Regarding try/catch block. I don't think that you should start implementing
it, since it is already implemented in extract method. The only thing we
have to do is to refactor the code a little bit and then we will get
surround with try/catch block for free.>
I thought about that, too
I will wait though
greets
Jens
Attachment:
patch20011210
Description: Binary data