[
https://issues.apache.org/jira/browse/THRIFT-2451?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13962366#comment-13962366
]
Ben Sigelman commented on THRIFT-2451:
--------------------------------------
I added the pointers to slices/maps partly for consistency, and partly because
a nil slice is actually a bit different than a pointer to a nil slice.
This is well-defined go code:
http://play.golang.org/p/IhzZ4Mzokp
... so a nil slice is (IMO) sufficiently confusable with an empty slice.
Of course this is not the case for Golang maps.
Anyway, here's what I actually care about:
- support for optional fields
- no special treatment of special values for various field types; esp 0 and "",
which are really very common and often *valid* values for numeric/string types
- no requirement for the user of the struct to maintain a bitfield
I don't actually like my patch very much, to be honest. I think it shows off
some problems with both the Thrift spec and Golang :) The only alternative I
could imagine was Getter/Setter interfaces and totally opaque implementations.
That would work well for the common case of numeric and string types, but it
runs into trouble when we get into the more esoteric set/map stuff. Or that's
why I stayed away from it.
But anyway! I don't mean to be a stick in the mud. I don't like the
proliferation of pointers much more than you do, but for optional fields, I
think they're our best bet given the combined requirements of Thrift and
Golang. If you want to do the heavy lifting to make an interface-driven
approach, then my hat goes off to you :)
> Go generated code should not initialize optional fields. Instead, Get
> accessors should be generated
> ---------------------------------------------------------------------------------------------------
>
> Key: THRIFT-2451
> URL: https://issues.apache.org/jira/browse/THRIFT-2451
> Project: Thrift
> Issue Type: Bug
> Components: Go - Compiler
> Reporter: Aleksey Pesternikov
> Assignee: Jens Geyer
>
> Currently, for optional fields in struct
> {code}
> struct pkt {
> 1: optional string s = "DEFAULT",
> 2: optional i64 i = 42,
> 3: optional bool b = false
> }
> {code}
> go compiler generates the following:
> {code}
> type Pkt struct {
> S *string `thrift:"s,1"`
> I *int64 `thrift:"i,2"`
> B *bool `thrift:"b,3"`
> }
> func NewPkt() *Pkt {
> rval := &Pkt{
> S: new(string),
> I: new(int64),
> B: new(bool),
> }
> *(rval.S) = "DEFAULT"
> *(rval.I) = 42
> *(rval.B) = false
> return rval
> }
> func (p *Pkt) IsSetS() bool {
> return p.S != nil
> }
> func (p *Pkt) IsSetI() bool {
> return p.I != nil
> }
> func (p *Pkt) IsSetB() bool {
> return p.B != nil
> }
> {code}
> which is wrong in multiple ways:
> 1. Freshly initialized fields returns IsSetField() true
> http://play.golang.org/p/T2pIX80ZJp
> This results in
> a. wrong semantics: freshly created struct has optional fields set
> b. excessive payload produced on serialization (writing field value
> instead of skipping it)
> 2. Additional load on garbage collector
> 3. accessing field value is complicated and error prone. even without default
> value:
> {code}
> if pkt.IsSetB() && *pkt.B {
> //do something for b==true
> }
> {code}
> would work for false default for field b. However, if I change default
> value to true, I need to change all occurrences in the code like this:
> {code}
> if !pkt.IsSetB() || *pkt.B {
> //do something for b==true
> }
> {code}
> How to fix that?
> there are two ways:
> 1. get back to generating inlines instead of pointers for optional fields
> with default value and compare with "magic value" of default in IsSet*().
> could be tricky since not all types are comparable
> http://golang.org/ref/spec#Comparison_operators . notably, slices and maps
> are not.
> 2. approach, used in protobuf: Do not initialize optional fields, generate
> Get*() accessors like this:
> {code}
> var Pkt_B_Default = false
> func (p *Pkt) GetB() bool {
> if p.B == nil {
> return Pkt_B_Default
> }
> return *p.B
> }
> {code}
> Just to make API uniform, we can also generate accessors for required fields:
> {code}
> func (p *Pkt) GetB() bool {
> return p.B
> }
> {code}
> I'm inclining to implement second approach, but I would like to collect
> opinions before I dig into the code.
--
This message was sent by Atlassian JIRA
(v6.2#6252)
