[
https://issues.apache.org/jira/browse/THRIFT-2429?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13975195#comment-13975195
]
Randy Abernethy commented on THRIFT-2429:
-----------------------------------------
Hello Aleksey,
The markdown posted for THRIFT-2486 attempts to provide a clear semantic and
mechanical definition for defaults of both types. The current state of the
proposal is to make "=" a "writer side default" and to make "=?" a "reader side
default" regardless of the field's requiredness.
So = works as always, both reader and writer initialize the field with the
default. Required will always serialize a value, normal will always serialize a
value and optional will serialize if set (and assigning the default sets the
field though the user can unset it before serializing). The default value is
thus typically set by the writer and found in the serialization stream.
The =? default is also initialized on both sides but not typically serialized
by the writer. Required fields with the default value will not be serialized.
Normal fields with the default value are not serialized. Optional fields with
the default value are not serialized. In all cases the reader's default is used.
There are pros and cons to all three cases, not using defaults, using writer
side defaults and using reader side defaults. By providing separate operators
we let the user choose their prefered implementation regardless of requirdness.
This approach keeps the choice distinct and symmetric, which I think is easier
to understand.
The implementation distinction for both forms is defined purely by the writer
(the read side treats both the same). A trivial implementation of =? can just
work like = (as Jens pointed out). Better implementations will omit some or all
default values based on the language implementor's assessment of implementation
trade offs. So day one we can just change the compiler code to use the same
code for = and =?. Because the reader is not affected this approach is backward
compatible as well, readers have always used their defaults for absent fields.
The one problem case is required which in new implementations would use the
default in the presence of =? rather than throwing when a value is not present.
This is just the mirror image of optional not being optional when you add a
default.
As always good docs and best practices are preferred over forcing one view on
all users. Some may find great value in reader side defaults for required
fields. The reason we moved to a new operator was to support those who want to
avoid transmitting defaults while keeping required/normal requirdness. Default
certainly impact the semantics of requirdness but they are essentially
orthogonal. More than anything I think the docs need to make all of this crisp
and clear.
If this approach is missing something you need or you have other ideas it would
be great to hear them. Also any improvements to the docs are welcome!
Best
Randy
> 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)
