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.
Update and clean up flight_planning interface #12
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
Update and clean up flight_planning interface #12
Changes from all commits
ec15fe7
e79234b
2bf1b3c
8843ecf
b4eb491
48b05ca
eef469a
b6dbaee
95cd17b
9adf551
bd56302
7eb6389
File filter
Filter by extension
Conversations
Jump to
There are no files selected for viewing
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.
nit: any reason why including
Unknown
and not just leaving the field empty in this case?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.
It's in an effort to be as accommodating to different tooling as possible. For instance, the problem-child of RPC tooling is Google's Protocol Buffers (protobuf) which is great when designing APIs using protobufs, but is not accommodating for many non-protobuf API design patterns. One specific proto3 "characteristic" (shortcoming? oversight? questionable design choice?) is that it is difficult to differentiate between default values and "missing", and it's difficult to actuate "omit" versus "default value". So, to maximize compatibility, a good API design practice is to specify an explicit default value that has the same effect as omitting the field. That way, tooling that prefers omitting values can do so, and tooling that prefers explicit values for all "primitive" (non-object) types can do so.
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, thanks for the clarification 👍