thrift-user mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From David Reiss <dre...@facebook.com>
Subject Re: default, required, optional
Date Fri, 31 Oct 2008 23:44:19 GMT
Yeah, defaulting isset to true would go most of the way.  There are
a couple of weird cases, though.

1/ When reading a structure, you would have to clear out __isset before
reading to distinguish between set and unset fields in the serialized
data.  One behavior that is possible now is to set some default values
in a structure and then read into it, effectively merging with the
serialized data.  If we clear out isset before reading, this behavior
would change a bit.

2/ If you read a structure, set more fields, and write it, you would
have to remember to set isset to true.

I think that, in general, the bugs that could be caused by making
optional the default would be subtle and dangerous enough that I'm
afraid of doing so.

Also, I think that while the implementation of Thrift might be simpler
with all default fields being optional, I think the interface would
be more complicated.  As it stands now, you won't ever be missing data
if you never turn on optional or learn about isset.

--David

Bryan Duxbury wrote:
> 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
> 

Mime
View raw message