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
