thrift-user mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Bryan Duxbury <>
Subject Re: default, required, optional
Date Fri, 31 Oct 2008 23:32:14 GMT
If people don't manually maintain __isset, but the fields in __isset  
defaulted to true, and everything was optional, then it would work  
exactly the same. If you wanted to manually maintain __isset, or were  
using generated code that did it for you (like the java:beans  
generator), then you could shave null fields.

On Oct 31, 2008, at 4:23 PM, David Reiss wrote:

> 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.
> --David
> 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