Closed chenhsi closed 10 years ago
I think I've got a fix in that works for this; currently testing. Involves checking that the equals sign is not enclosed in something (e.g. parentheses, brackets, etc.). Somewhat hacky. Will test for a bit before committing.
Committed. Really wish GitHub had a "test" status for issues, but w/e. If we find bugs in it, reopen and revert commit 5a5c407d48b9c1160a7f253822e157338bbe8799.
So, I was hoping to avoid the slightly unintuitive (>.> is this not conventionally recognized as a word) operator of "==", by simply using "=" for both equality and assignment, and using context to determine which is the intended usage (which definitely won't create any confusion at all).
That said, I realized that, presently, our program would fail to distinguish properly between the two under certain situations involving call lines, e.g. "f(x = y)". While it is clear that this is a usage of equality, the way Line.java currently distinguishes between AssignmentLines and CallLines is whether they have an "=" in them or not.
I had imagined that the solution to this bug is for Line to read an entire Expression, and see if there are any more tokens afterwards, thus distinguishing between an AssignmentLine and a CallLine. However, as "=" is also an operator, Expression would interpret a line such as "x = 3" to be applying the equality operator to the operands "x" and "3", so I am uncertain as to how to properly deal with all cases.
Alternatively, we could just go with "==" for equality, a "fix" I am temporarily applying. I would be a sad chenhsi in regards to the syntax, but this should technically solve all the problems.