Conversation
| import software.amazon.smithy.utils.SmithyInternalApi; | ||
|
|
||
| /** | ||
| * WARNING 1/29/26: AVOID any new usages of these. |
There was a problem hiding this comment.
i don't remember why i wrote this
|
|
||
| // Other traits | ||
| GENERATORS.put(ContextParamTrait.ID, new SimpleTraitGenerator<>(SMITHY_TRAITS.struct("ContextParam"))); | ||
| GENERATORS.put(AwsQueryErrorTrait.ID, new SimpleTraitGenerator<>(SMITHY_TRAITS.struct("AWSQueryError"), |
There was a problem hiding this comment.
do we
- do it like this
- put aws traits in their own module?
There was a problem hiding this comment.
I would prefer only pass 1 string-func key value pair to the generator's constructor (unless some trait like error/status code must be bounded together), or maybe we can pass key value separately as list in order.
There was a problem hiding this comment.
i mean now we have SimpleTraitGenerator(symbol, k1, v1) and SimpleTraitGenerator(symbol, k1, v1, k2, v2), which might be merged to a single constructor like SimpleTraitGenerator(symbol, List<k>, List<v>)
There was a problem hiding this comment.
I'm not really a fan of that personally, I think the ergonomics of k/v are way better. It matches how the constructors of Map.of are defined.
There was a problem hiding this comment.
Java should really just have actual map literals but unfortunately it doesn't.
| import software.amazon.smithy.model.shapes.ShapeType; | ||
|
|
||
| public class UnsupportedShapeException extends CodegenException { | ||
| public UnsupportedShapeException(ShapeType type) { |
There was a problem hiding this comment.
part of the serde that got left behind
codegen/smithy-go-codegen/src/main/java/software/amazon/smithy/go/codegen/util/ShapeUtil.java
Show resolved
Hide resolved
codegen/smithy-go-codegen/src/main/java/software/amazon/smithy/go/codegen/CodegenVisitor.java
Show resolved
Hide resolved
| m := &Schema{ | ||
| id: ShapeID{Member: name}, | ||
| typ: target.typ, | ||
| members: target.members, |
There was a problem hiding this comment.
out of curious: is there a reason you not clone the members like you do for traits?
There was a problem hiding this comment.
so for members, we don't want to be cloning them because that would mean every member shape clones all of its members down its shape tree recursively. the member lists don't get modified so it's also just not necessary.
for traits we have to clone them because we combine member and target traits here (we don't want to disturb the original target trait map)
2 participants
part of #458
Schemas are trimmed-down descriptions of shapes in the model. Schemas are used in the new (NYI) (de)serialization in place of model-ignorant/static generated code.
Right now generation of these is gated behind a new "useExperimentalSerde" setting so there are no downstream codegen changes (and that aside we're merging this to a feature branch).
The serde itself has already been largely bootstrapped, I yanked it out of this so we could review schemas on their own but FYI there might be random import changes / utility APIs seemingly there for no reason that I missed, they were likely added for serde.
Their may be slight API changes to schemas as part of serde but the general layout of schemas and traits, as well as all the codegen for them, should be 99% stable.
gist with generated example schema for sqs: https://gist.github.com/lucix-aws/2e85bd115e51aca977a2a79eb04ba428
preview of what generated serializers look like with schemas: https://gist.github.com/lucix-aws/2a17ad38f46f0b1f9b2f4c8252a89687