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:59:14 GMT
Comments inline.

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

> 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.
Merging structs together like this is a little weird from the start.  
If you can do this now, it means you can't reuse the same structure  
instance to read subsequent items off the wire without manually  
clearing them, which is pretty awkward. If merging structures is a  
desired usecase, then there should be separate methods for it.

> 2/ If you read a structure, set more fields, and write it, you would
> have to remember to set isset to true.
I see what you are saying here. Again, though, this only bites you if  
you are using code that doesn't manage the __isset for you. Maybe I'm  
biased because I used java:beans and Ruby, both of which aren't  
affected by __isset issues like this one. Which other libraries are?  
For the ones that are, can they use getter/setter or property  
functions to simulate the same use pattern but still maintain the  
__isset properly?

> 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

View raw message