Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

[#64] Split type Number #72

Merged
merged 2 commits into from Aug 11, 2018
Merged

[#64] Split type Number #72

merged 2 commits into from Aug 11, 2018

Conversation

grizio
Copy link
Contributor

@grizio grizio commented Aug 11, 2018

To be more robust and keep a logic in our code, split the type Number.

This change imply to correct lot of tests to consider the new types.
However, the production code was not a big change.

This commit does the following:

  • Correct antlr definition to identify both integers and numbers
  • Create type IntegerValue to recognize an integer instead of a number
  • Rename controls CalculatorOperandsAreNumber and OrderOperandsAreNumber to be more expressive
  • Calculator and orders must be on the same numeric type to avoid risks in target languages
  • Correct tests to use the right numeric type when there was a confusion between the two
  • Add test ensuring that the same numeric type is used in calculator and order expressions

This PR resolves #64.

Gaëtan Rizio added 2 commits August 11, 2018 21:14
Adding some tests, we saw that the symbol `/` did not work.

The reason comes from `contextContentSymbol` that redefined `/`
instead of using `CALCULATOR_OPERATOR_LEVEL_1` only.
This created an identifier in antlr incompatible with `CALCULATOR_OPERATOR_LEVEL_1`.

This commit does the following:

- Remove usage of `/` in `contextContentSymbol`
To be more robust and keep a logic in our code, split the type `Number`.

This change imply to correct lot of tests to consider the new types.
However, the production code was not a big change.

This commit does the following:

* Correct antlr definition to identify both integers and numbers
* Create type `IntegerValue` to recognize an integer instead of a number
* Rename controls `CalculatorOperandsAreNumber` and `OrderOperandsAreNumber` to be more expressive
* Calculator and orders must be on the same numeric type to avoid risks in target languages
* Correct tests to use the right numeric type when there was a confusion between the two
* Add test ensuring that the same numeric type is used in calculator and order expressions
@grizio grizio merged commit 1b32cbd into master Aug 11, 2018
@grizio grizio deleted the 64-split-type-number branch August 11, 2018 19:43
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

Successfully merging this pull request may close these issues.

Split type Number
1 participant