SpartanRefactoring
0+(x+Y + 0 + 2) ???
can anything be done for 0+(x + 0 + y + (x + 2), without knowing the type of x or y? I doubt it, yet the tests say it is possible...
`
I worked on InfixAdditionZero2 class and it is working fine on its own. However, when placed in the toolbox it leads some tests to fail. That's because there is a "conflict" between the tests - and specifically, some "test fixtures", namely some of the strings that are input of the trimmingOf or assertConvertsTo (and the like) methods, trigger multiple tippers (also depending on the position of the tipper on the list of the corresponding ASTNode). For example, the ternarize18 on FixedPointTest fails with the following AssertionError:
java.lang.AssertionError:
Expected: is "x.y.f(X.equals(X)?tH3+X:h2A+X+0+X);"
but: was "x.y.f(X.equals(X)?tH3+X:h2A+X+X);"
This is because InfixAdditionZero2, that runs before the tipper tested by ternarize18, removes the 0, altering the input string. I guess that it should be also influenced by the the "first comes, first served" policy we are adopting" since the first compliant tipper is picked up and run. As mentioned, depending on the position of the tipper in the toolbox the number of tests that fails is different (17 if I place the tipper on the top, more than 20 if I put it at the very bottom). For the moment I removed the tipper from the Toolbox. I am looking for a way to fix these conflicts. Any suggestion from all of you is very welcome.
This is an issue with every new tipper. Usually the solution is to correct the failing tests, while preserving the original purpose. It should not matter where you place the tipper in the toolbox (besides tests). If you want you can ask the original writer of the tests to help you out.
@yossigil some of the unit tests seem wrong. for example:
trimmingOf("0+x+y+4")//
.gives("x+y+4")//
is wrong since x may be a string, in which case the 0 cannot be remove. If it was 0+x+y-4 we could have removed the 0, since the - would tell us it isn't string concating. But since it is a plus we don't know anything. Same for
trimmingOf("0+0+x+4*y")//
.gives("x+4*y")//
here as well, x may be a string, in which case the 0 cannot be removed.
Also, in my opinion, this tipper should ask type#isNotString if it can work or not (perhaps the name should be changed to something like itNotStringConcating, since that's the only use), and if namespace can improve our abillity to tell whether this is string concating or not, then that should be added to type, since there are a few other tippers who also deal with the exact same issue using type#isNotString.
I know this isn't realated to the yearly project, but I got an email on this and though I should share my thoughts on this, since it relates to most of what I did during the summer.
I agree. It was so confusing that some of the tests where wrong. In the case 0+x, we can eliminate the zero, if x might be int/Integer/double/Double/.... , you say it is the same as "StringOrObject'?
can you check and finish with this one? fix tests which are wrong, make the semantics as safe as possible, and close?
Ok, I'll take over this, though I'll need help from @dormaayan to see how namespace can help here.
@NivShalmon : As per our discussion today: use the environment/namespace (talk to @dormaayan on how) to make an educated guess re-type.
type does this properly now, but the tipper in question is a different question. there are two tippers (infixAdditionZero and infixAdditionZero2), and both fail some tests. Of the two, infixAdditionZero is better, since it doesn't work when it isn't supposed to, unlike infixAdditionZero2 which may cause bugs. Moreover, both tippers don't seem to use type at all, which means this change to type I did won't solve doesn't change anything for this issue yet.