[
https://issues.apache.org/jira/browse/THRIFT-2429?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13967540#comment-13967540
]
Ben Sigelman commented on THRIFT-2429:
--------------------------------------
Hi Randy,
Thanks for the detailed explanation, very helpful! And also thank you for your
patience.
I certainly couldn't agree more regarding your last point (about docs); I
apologize for spending so much of your time explaining the semantics to me.
But onwards about this debate: as I presently understand it, {{normal}} fields
are always "set" (or, really, they don't present the set/unset dichotomy in the
first place). This distinction between {{optional}} and {{normal}} (set/unset)
also has me continuing to believe that {{optional}} is more than an
optimization; fields marked {{optional}} have different semantics than fields
un-marked {{normal}} (if I am understanding correctly). I can give some
examples of times when I think it's beneficial to have set/unset; certainly for
interface evolution, and even otherwise.
Given that some users (e.g., me) are using {{optional}} for *semantic* reasons,
is it really safe to treat it as an optimization? Furthermore, let's say that I
like using {{optional}} as an optimization; I don't like sending unset fields
over the wire any more than the next guy or gal. Even then, I don't see a good
argument for making {{default}}-valued fields an implicit part of the
serialization format.
Please do let me know if I'm missing something else about {{normal}} fields and
set/unset!
Thanks, Ben
> 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)
