thrift-user mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From David Reiss <>
Subject Re: default, required, optional
Date Fri, 31 Oct 2008 23:23:58 GMT
Because that would require that __isset be manually maintained,
which is an inconvenience that impedes a natural programming style
when working with structures that are not sparse.


Bryan Duxbury wrote:
> Is there any reason to serialize unset fields, ever? It seems like a
> key attribute of Thrift to have nulls omitted. The only difference
> between optional and default is that types that cannot be null will
> be serialized regardless of __isset. Why don't we just always check
> __isset, and default to all __isset fields true?
> Basically, I think it'd be a lot simpler if we eliminated the default
> state altogether, and I don't think we'd be losing any functionality.
> On Oct 31, 2008, at 1:23 PM, David Reiss wrote:
>> The default replicates the behavior that existed before required and
>> optional were added.  These fields are always set when serializing,
>> regardless of the value of __isset.  This means that programmers do
>> not
>> have to manually maintain __isset.  (Actually, the fields are not
>> serialized if they are null in languages that allow it.)  However,
>> when
>> deserializing, no error is thrown if a default field is not present
>> (for
>> example, if it was sent by an older client or server, or if it was
>> null).
>> --David
>> Bryan Duxbury wrote:
>>> Can someone help me understand the difference between required,
>>> default, and optional field modifiers? Required seems to make sense.
>>> Optional seems to make sense. However, the fact that there's a third
>>> state is quite ambiguous.
>>> It seems like the field modifiers should be binary - required or
>>> optional. Leaving the modifier off should just be a shorthand for
>>> optional.
>>> -Bryan

View raw message