-
Notifications
You must be signed in to change notification settings - Fork 187
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
Refactor redactIfNecessary
function
#1746
Refactor redactIfNecessary
function
#1746
Conversation
It's useful to call `redactIfNecessary` on arbitrary shape types, not only member shapes. It is now an extension function on `Shape`, with a specialization on `MemberShape`, since note that the `sensitive` trait cannot be applied to member shapes [0, 1], so we traverse to its target directly. Ultimately this is just to make the diff of #1342 lighter. [0]: https://awslabs.github.io/smithy/1.0/spec/core/documentation-traits.html#sensitive-trait [1]: https://awslabs.github.io/smithy/1.0/spec/core/documentation-traits.html#sensitive-trait
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.
Makes sense. LGTM
A new generated diff is ready to view.
A new doc preview is ready to view. |
fun MemberShape.redactIfNecessary(model: Model, safeToPrint: String) = | ||
model.expectShape(this.target).redactIfNecessary(safeToPrint) | ||
|
||
fun Shape.redactIfNecessary(safeToPrint: String) = |
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 think this could be error prone. For example, if someone calls Shape.redactIfNecessary
on a MemberShape
, which is possible since a MemberShape
is a shape, then that might result in the wrong code generated behavior, right? Perhaps we should just have one function that always takes a model, and do any necessary switching logic based on the type in that.
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.
Yeah, it crossed my mind that this could be error prone.
if someone calls Shape.redactIfNecessary on a MemberShape, which is possible since a MemberShape is a shape, then that might result in the wrong code generated behavior, right?
Yes. I think there's an argument to be made that it's a mistake on behalf of the caller, since sensitive
cannot be applied to member shapes. I only introduced MemberShape.redactIfNecessary
as syntax sugar for the caller to not have to traverse to the member's target, but I don't know if I prefer to lay that responsibility on the caller, or to have a single function that always takes in model
like you suggest. All 3 ways are reasonable.
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.
…dact-if-necessary-function
939fcb6
to
869afa4
Compare
A new generated diff is ready to view.
A new doc preview is ready to view. |
It's useful to call
redactIfNecessary
on arbitrary shape types, notonly member shapes.
It is now an extension function on
Shape
, with a specialization onMemberShape
, since note that thesensitive
trait cannot be appliedto member shapes [0, 1], so we traverse to its target directly.
Ultimately this is just to make the diff of #1342 lighter.
Testing
No diff in generated artifacts.
By submitting this pull request, I confirm that you can use, modify, copy, and redistribute this contribution, under the terms of your choice.