-
Notifications
You must be signed in to change notification settings - Fork 9
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
Protobuf specification rework #131
Conversation
use alloy#uuidFormat | ||
use alloy.proto#protoCompactUUID | ||
|
||
@protoCompactUUID |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
smithy translate did that for shapes with the type:alloy#UUID
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I'm aware. We shouldn't use shapeIds to discriminate behaviour, it's pretty unsound. Using traits is much better.
I guess your point is that we could apply that trait to the alloy#UUID
idea to retain the current behaviour.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
One potential downside of applying it to alloy#UUID is then the alloy core namespace would depend on the proto one which I'm not sure we want (maybe fine though)
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I did not know you were aware, I agree with you that the trait is a better approach now that I know better!
But as jeff points out, I don't think introducing a dependency between the two artifacts is desired so I would just leave it like that
use alloy#uuidFormat | ||
use alloy.proto#protoCompactUUID | ||
|
||
@protoCompactUUID |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
One potential downside of applying it to alloy#UUID is then the alloy core namespace would depend on the proto one which I'm not sure we want (maybe fine though)
Co-authored-by: David Francoeur <dfrancoeur04@gmail.com>
Co-authored-by: David Francoeur <dfrancoeur04@gmail.com>
modules/core/src/alloy/proto/validation/ProtoMapKeyValidator.java
Outdated
Show resolved
Hide resolved
Co-authored-by: David Francoeur <dfrancoeur04@gmail.com>
Co-authored-by: David Francoeur <dfrancoeur04@gmail.com>
Co-authored-by: David Francoeur <dfrancoeur04@gmail.com>
} | ||
|
||
test( | ||
"int-enum - no-zero on open enums is valid if protoIndex(0) is present" |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I just realized this test title mentions OpenEnumTrait
but it's not used in the code, so either the title is wrong, of the annotation was forgotten on the intEnum member
Rework the protobuf specification.
The goal is to allow for more control over what should be wrapped in messages and what should not be wrapped, avoiding implicit rules that prevent sound refactoring/evolutions of smithy specifications.
In particular :
alloy.proto#protoWrapped
trait that can be added on simple shapes + lists + maps + members targeting those. This is the only signal allowed for deciding whether something should be wrapped or not.gRPC
orprotoEnabled shape
. These rules ported from the proto language, such as (but not limited to) :@protoWrapped
@protoWrapped
alloy-protobuf
artifact with proto files containing messages that can be used by smithy-translate and other tools to facilitate the abidance to the rules described in the alloy protobuf specificationThis PR is to remain a draft until the semantics described in it are incorporated in smithy-translate and validated in some "smithy4s-protobuf" POC