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

add codegen support for string array and operation context params in endpoint bindings #519

Merged
merged 2 commits into from
Jun 26, 2024

Conversation

lucix-aws
Copy link
Contributor

  • Add a GoCodegenContext field to CodegenVisitor and pass it down. This context object contains a handful of principal codegen resources which everything generally needs, and passing it simplifies a lot of constructor calls (observe the difference in OperationGenerator. This matches the new DirectedCodegen pattern.
  • Adds a basic JMESpath expression generator. This is used for the new "operation context params" binding trait but lays the groundwork for getting rid of runtime jmespath in the future (refactor smithy-waiters to remove jmespath dependency at runtime #238).
  • Add support for STRING_ARRAY type of endpoint parameter
  • Add support for jmespath-based operation context params

}

private Result visit(JmespathExpression expr, Shape current) {
if (expr instanceof FunctionExpression) {
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

[nit] Since Java 17 you can do

if (expr instanceof FunctionExpression fexpr) {
    // look ma, typecasting is already done
    return visitFunction(fexpr, current)
}

[also nit, but tangential] if we could switch to Java 21 we could even do Pattern Matching and do something like

return switch (expr) {
    case FunctionExpression fexpr -> return visitFunction(fexpr, current);
    ....
}

* trying to recursively compose/organize Writable templates.
*/
@SmithyInternalApi
public class GoJmespathExpressionGenerator {
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

We should really have tests for this class

var lookahead = new GoJmespathExpressionGenerator(ctx, new GoWriter(""), leftMember, expr.getRight())
.generate("v");

++idIndex;
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

not quite sure I follow why we increase the index when visiting the projection. Each field increases the index because we're visiting a concrete field, but why do we increase it here?

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

We need a new identifier for the slice variable that holds the result of the overall projection (it's declared in the following write()).

return new Result(listOf(STRING_SHAPE), "v" + idIndex);
}

public record Result(Shape shape, String ident) {}
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

<3

@lucix-aws lucix-aws merged commit 5a2e64e into main Jun 26, 2024
11 checks passed
@lucix-aws lucix-aws deleted the feat-epstringarray branch June 26, 2024 14:58
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

3 participants