Bryan,

I looked through the Java library and see the "__isset_bit_vector"
field it generates. That's a good idea.

This would then require a change in the Go compiler to generate all of
the struct fields as lower case (internal), as opposed to external as
they currently are. This would prevent users from accessing the struct
variables, except through their accessor methods. Then the struct
accessor methods could do something similar to the __isset_bit_vector
pattern to correctly implement the "optional" fields.

This sounds reasonable to me.

Thoughts on this?

Thank you.

Trevor

On Wed, Jun 8, 2011 at 1:44 PM, Bryan Duxbury <br...@rapleaf.com> wrote:
> In the Java library, we added extra "is set" flags for fields that could not
> be nulled out but could be not set.
>
> On Wed, Jun 8, 2011 at 10:38 AM, Trevor Smith <tre...@knewton.com> wrote:
>
>> Hello,
>>
>> The current Go compiler implementation in Thrift does not deal
>> correctly with optional struct values. This, for example, makes
>> compiling the Cassandra Thrift interface unusable, because it sends
>> along optional string values as zero length strings, when it should in
>> fact be skipping the field altogether.
>>
>> I am working on a patch to fix this. For many Go datatypes this is
>> straight forward (ie types that can be represented as nil in Go).
>> However, it is not clear to me how to generate Go code that does the
>> optional check for string and integer types -- specifically to allow a
>> string zero length string or an integer of value 0 in an optional
>> field, versus the non inclusion of those values. This is because Go
>> sets integer and string types to 0 and "", respectively, as their
>> default values.
>>
>> Literally, I do not know how to:
>>
>> // Create the code to make a decision as to include or not include a
>> struct field in
>> // t_go_compiler.cc: generate_go_struct_writer
>> if (item->get_req() == t_field::T_OPTIONAL && /* type is int and zero,
>> what to do? */( {
>> }
>>
>> Any suggestions would be appreciated.
>>
>> Thank you.
>>
>> Trevor Smith
>>
>

Reply via email to