| 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