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
