TEDEFO-5142, TEDEFO-5144: Transpile EFX selectors to element paths - #171
Merged
Conversation
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
This pull request implements, in both expression translators, the selector added to the EFX-1 and EFX-2 grammars under TEDEFO-5141 and TEDEFO-5143.
A selector yields the same path that the equivalent expression would use, without the final step that reads the value. It is relative or absolute according to how the reference is written. The translated result is therefore a location path rather than a sequence of values, and can be used to select the elements the reference designates.
The version of the SDK from which the EFX-1 grammar is generated moves from 1.13.0 to 1.16.0-SNAPSHOT, which is the first version to contain the selector. The two grammars were otherwise identical, so no other change follows from it.
The implementation is one listener method in each translator. The path produced by the reference is already on the stack, so the only work is to leave the value step uncomposed. An attribute reference needs its attribute step composed there, because attributeReference has no exit handler of its own; composing it globally would apply it twice in the scalar and sequence positions and change existing output.
One difference between a selector and an expression is worth noting. An indexed selector uses the node-level indexer that fieldContext applies everywhere else in the language, as it does for rawValue, context iterators and context overrides, and therefore selects the nth occurrence within each parent. An indexed expression indexes the sequence of values and selects the nth item overall. This is deliberate and is covered by a test, so that the two forms are not mistaken for one another.
The suite contains 1373 tests, all passing. The output of the existing corpus is unchanged, and the build was verified against the published snapshots of both SDK branches rather than local installations.