[
https://issues.apache.org/jira/browse/THRIFT-2429?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13967671#comment-13967671
]
Randy Abernethy commented on THRIFT-2429:
-----------------------------------------
Hey Ben,
Thanks for the ongoing thoughtful discussion. Great to vet all this stuff. You
make a good point on the semantic front and I agree. Optionality is an
important semantic.
The issue at hand, "providing the option to not write default values", is
mechanical in nature and the optimization comment was directed at that level. I
often try to think about interfaces in three orthogonal vectors, this may help
frame our discussion around this issue:
* Mechanical - what's going to be serialized and how
* Semantic - how the interface maps to my domain constructs/concepts today
* Evolution – how will changes affect the interface (this is tied to mechanics
but is useful to consider separately I find)
Thrift IDL defines all three of these vectors. Relative to THRIFT-2429 and
considering the field:
bq. 1: optional i32 x = 10
*On the mechanical front:*
Presently Thrift sets x to 10 (possible overwritten with another value by the
writer) and then x is serialized. THRIFT-2429 suggested that if x is 10 at
serialization time it will not be serialized. You can unset the field today to
avoid transmission so THRIFT-2429 only adds the convenience of implicitly
unsetting the value if it holds the default. [Default values are unsafe if
changed over time (true independent of THRIFT-2429, though more true with
THRIFT-2429) with the exception of required field defaults. It is safe to
change the default of a required field because required fields are always
present in any version of the interface and always transmit their defaults,
making default values the one aspect you can evolve in a required field.]
*On the semantic front:*
In our example some may interpret x semantically as an element of the interface
with optionality. This would be a mistake. Adding a default value to an
optional field changes the semantic. How can you have a default for something
with optionality? Default implies a value is always present. If the writer sets
x the reader will see the set value but if the writer unsets x, (regardless of
THRIFT-2429) x will be received with the default value by the reader. The
semantic of an optional field with a default value today (regardless of
THRIFT-2429) is the same as that of a normal field. The difference is not
semantic, it is mechanical, the writer of an optional field with a default
value can unset the field, as a mechanical optimization, to not transmit it. A
normal field with a default value provides no such ability. So it is the case
today that "optional" imparts mechanical attributes to a field (that of
selective transmission) and in the presence of default values, this is the
exclusive feature attributed. "Optional semantics" are not imparted when
default values are in play, the value will always be found by the reader).
Default values have primacy over requiredness.
*On the evolution front:*
If the writer knows x and the reader doesn't we are fine. Readers ignore
unknown fields (present or not present). If the reader knows x and the writer
doesn't the reader will see the default value for x. This is the behavior we
have now. If a field has a default value, the reader will always receive that
field (whether it is in the stream or not). Default values have primacy over
requiredness. This is the most significant feature to raise attention to in my
estimation, but nothing new.
To summarize from the writer's perspective, what we have today is:
* required - I will serialize this forever
* normal - I will serialize this as long as it is a part of my interface
* optional - I will serialize this if it is appropriate in the context of this
call
* ----
* required/default - I will serialize this forever, the default simply
initializes the writer's side
* normal/default - I will serialize this as long as it is a part of my
interface and the reader will use the default when the value is not in the
stream
* optional/default - I will serialize this if it is appropriate in the context
of this call and the reader will use the default if a value is not found in the
stream.
[Required and normal without a default can impair one's ability to evolve an
interface.]
THRIFT-2429 currently proposes to change the definition of "appropriate" in the
last bullet to elide the case where the value is equal to the default.
Thoughts?
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)
