[
https://issues.apache.org/jira/browse/THRIFT-2429?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13975505#comment-13975505
]
Randy Abernethy commented on THRIFT-2429:
-----------------------------------------
Hey Aleksey,
I hear you and understand the concern, note that I suggested the use of
optional with default for this feature at the top of this issue for exactly the
reasons you mention.
We are here because some people want reqIn/optOut (normal requirdness as we
have been calling it) but the ability to omit defaults in the stream. A
reasonable request really. I greatly prefer using normal requirdness (no
setters) to optional unless the field is truly optional. This approach allows
normal fields to benefit from default eliding with =?.
Required fields must be present in the stream today as you say. The proposal is
to allow them to be omitted when =? defaults are in play. The semantic is still
required. The reader will always find the value, even if it is a locally
initialized default. The writer must write everything but the default.
This is the mirror image of what = defaults do to optional today. An optional
field with a default value is no longer semantically optional. This is a more
serious transgression in my mind but we have lived with it since inception.
Optional fields with default values will always be present on the read side
with the default value at minimum (and usually transmitted).
So the goal here is to give all camps what they need and to do it in a
consistent and easy to explain way. You can:
- never use defaults
- use defaults that always serialize (=)
- use defaults that typically don't serialize (=?)
You can also decide which requirdness to use each with. I can easily imagine
scenarios where I might want = with some normal requirdness fields and =? with
some other normal requirdness fields. I also like the fact that we are leaving
= alone avoiding compatibility issues.
Maybe we need to do a better job of describing the interaction concerns with
default values and requirdness.
Would you be more comfortable if we made =? work like = in the case of required
fields? While that exception complicates the explanation of defaults it does
avoid the possible incompatibility that introducing =? defaults could cause
with required fields in an evolving interface.
I would really like everyone to be happy with where we come out on this. Let me
know what you think.
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)
