[
https://issues.apache.org/jira/browse/THRIFT-2429?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13967689#comment-13967689
]
Ben Sigelman commented on THRIFT-2429:
--------------------------------------
Thanks for the detailed explanation once again.
So, firstly, I would never want to imply that there's any need to actually
*convince* me about
[THRIFT-2429|https://issues.apache.org/jira/browse/THRIFT-2429].
That said, I'm not convinced ;)
In my view, Thrift exists as an intermediary between multiple distinct versions
of software. If we were only concerned with version N talking with version N,
of course things would look much different than they do!
Given my personal preference to make tradeoffs in favor of interface evolution,
you will be unsurprised to hear that I still think that default values for
optional fields should be serialized.
To be specific (albeit redundant with earlier messages), these are the rules I
would propose for optional fields...
*upon construction:*
- optional fields without defaults are marked as {{unset}}
- optional fields with default values are marked as {{set}}, and take on that
default value
*upon serialization:*
- optional fields are serialized if and only if they are marked as {{set}}
Deserialization is obvious, I think: first the message is constructed exactly
as above. And if there's a value for the given field specified in the
serialized form, it is used and the field is marked as {{set}} if it wasn't
already.
And that's it. If a user is so concerned about serialization bulk that they
want to not-serialize default values, they would have to clear/unset their
optional field before serializing. *Most importantly*, in so doing they would
have to *know* that all possible present and future readers of the serialized
form also know about the default! Which is the crux of my objection. That is
something only the application owner *can* know. There is no way for Thrift
maintainers to safely make that generalization... certainly there have been
several instances in my own work (with PB, admittedly) wherein the above
assumption would have broken my code. (Of course I would have just chosen not
to use default values, but they *are* handy, and that would seem a shame)
In closing, I do think that
[THRIFT-2429|https://issues.apache.org/jira/browse/THRIFT-2429] is overly
optimistic about the amount of control that developers have over the lifetime
of both their software and their serialized messages. Perhaps I'm wrong,
though... certainly if software deployments were instantaneous and defaults
never change, [THRIFT-2429|https://issues.apache.org/jira/browse/THRIFT-2429]
is downright beneficial. So I think the real question is about which sort of
situation Thrift wants to design for. I'm obviously in the camp that think we
should be optimizing for heterogeneous software/message versions.
Thanks again for the enjoyable back-and-forth! I'll be curious to see how this
turns out, but won't intervene any more unless you or others have any questions
about my proposal, which you should take or leave as you see fit.
Best wishes,
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)
