[
https://issues.apache.org/jira/browse/THRIFT-2429?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13966737#comment-13966737
]
Ben Sigelman commented on THRIFT-2429:
--------------------------------------
Thanks, Randy. I did a little bit of research about this, and came away with
the sense that {{required}} is not equivalent to {{optional}} in PB. E.g., this
passage:
{quote}
Required Is Forever:
You should be very careful about marking fields as required. If at some point
you wish to stop writing or sending a required field, it will be problematic to
change the field to an optional field — old readers will consider messages
without this field to be incomplete and may reject or drop them
unintentionally. You should consider writing application-specific custom
validation routines for your buffers instead. Some have come the conclusion
that using required does more harm than good; they prefer to use only optional.
However, this view is not universal.
{quote}
(That's taken from [this
document|http://diwakergupta.github.io/thrift-missing-guide/#_defining_structs])
I tried and failed to find the doc that precisely described the semantics of
{{required}} underneath thrift.apache.org... I'd be happy to RTFM if you help
find it for me.
If {{required}} in thrift is indeed equivalent to {{optional}} in PB, then I
guess I'm less concerned about this proposal but considerably more confused
about Thrift :)
> Provide option to not write default values, rely on receiver default
> construction instead
> -----------------------------------------------------------------------------------------
>
> Key: THRIFT-2429
> URL: https://issues.apache.org/jira/browse/THRIFT-2429
> Project: Thrift
> Issue Type: Improvement
> Components: C++ - Compiler
> Affects Versions: 0.9.1
> Reporter: Chris Stylianou
> Assignee: Randy Abernethy
> Labels: default, optional, required
>
> Would there be any objections to a patch that does not write default values
> (essentially the same logic as the optional attributes). This obviously
> relies on the receiving application using the same IDL version to ensure the
> defaults used on object construction match the senders.
--
This message was sent by Atlassian JIRA
(v6.2#6252)