[
https://issues.apache.org/jira/browse/THRIFT-2429?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13967905#comment-13967905
]
Randy Abernethy commented on THRIFT-2429:
-----------------------------------------
Hey Jens,
Well said. The discussion really gave me a chance to think about how different
the PB and Thrift requiredness options are. Perhaps we need a "Thrift for PB
programmers", page as well.
Like you I remain convinced that we need to add the capability to not transmit
default values. Because of the push back I have been trying to think of other
ways we can do it. These are the options I can think of (the first two already
implemented in fbthrift):
* 1. Compiler switch, e.g. $ thrift --gen py --default-off my.thrift}
* 2. IDL annotation, e.g. {struct { 1: i32 "default_off" x = 10 }
* 3. optional fields with a default value, e.g. struct { 1: i32 optional x
= 10 }
* 4. New default value “no serialize” operator, e.g. struct { 1: i32 x ~ 10
}
* 5. New IDL keyword, e.g. struct { 1: i32 x = 10 del }
Each has pros and cons.
I personally don't like #1 because it moves important interface mechanics out
of the IDL and applies to an entire compilation unit.
I don't like #2 because annotations to me are a way to deploy language specific
features, there's no reason all languages shouldn't work the same way here.
We have pretty thoroughly discussed the pros and cons of #3. One of my new
reservations with this approach is that in Dave's Facebook patch you can omit
defaults in normal requiredness fields, if this becomes important, solution 3
will limit us.
Solution #4 means adding a new operator to the compiler, which upon reflection
is not awful (could be any operator).
Solution #5 means adding a new keyword to the compiler, which is never a great
thing to do, though there are plenty of reserved words (like "del") which could
be deployed with positional semantics to future proof them somewhat.
Curious to see if any of these are preferable to folks or if anyone can think
of other possibilities.
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)
