Setters?

[GoogleCodeExporter]

I saw that you added getters, are you planning on adding setters?

Original issue reported on code.google.com by awalterschulze on 9 Jul 2012 at 9:32

[GoogleCodeExporter]

We aren't planning on adding setters. Getters are special because they 
implement the proper protocol buffer field semantics w.r.t. default values, but 
there's no such complication with setters, so there's no need for the code 
bloat.

Original comment by dsymo...@golang.org on 9 Jul 2012 at 9:41

• Changed state: WontFix

[GoogleCodeExporter]

It is quite sad to write
*someMessage.SomeIntField = 1
or
*someMessage.SomeIntField = someIntReturningFunction()
, because of the dereference
and importing proto is also quite sad if you don't want coders to know the 
difference between protocol buffer generated structs and just any other struct.

Setters are not the best thing, but they are better than the alternatives.

The best thing would be if you could write

someMessage.SomeIntField = 1

Original comment by awalterschulze on 9 Jul 2012 at 2:42

[GoogleCodeExporter]

You can write
  someMessage.SomeIntField = proto.Int32(1)

I agree protocol buffer structs are a bit different to normal Go
structs. Unfortunately that's the way it is with protocol buffers.

Original comment by dsymo...@golang.org on 9 Jul 2012 at 10:25

[GoogleCodeExporter]

Currently we are generating protocol buffers from go structs, since the code to 
interact with protocol buffers isn't very goey.
Then there is also generated code to transfer the data between these structs.
This is becoming an intractable problem.
I am close to tackling this problem from the more obvious direction.
This requires making a code generator that will generate protocol buffers 
without the pointers for each field.
May I ask what the reason is that goprotobuf generates the fields with pointers?
Then there will be no need for getters or setters.

Original comment by awalterschulze on 16 Jul 2012 at 1:15

[GoogleCodeExporter]

Protocol buffers specify that it is possible to distinguish between a
field being set and a field having its default value, as bizarre as
that may seem. Thus a plain value is not sufficient representation,
and we decided that pointers were the least of the possible evils.

Original comment by dsymo...@golang.org on 16 Jul 2012 at 1:19

[GoogleCodeExporter]

Why do required fields also use pointers?

Original comment by awalterschulze on 16 Jul 2012 at 3:40

[GoogleCodeExporter]

Primarily because of consistency. It has other benefits, though, like
being able to re-use the same memory across multiple structs.

Original comment by dsymo...@golang.org on 16 Jul 2012 at 11:15

[GoogleCodeExporter]

You are trying to spin pointers into a positive, but I contend they require 
more mallocs in most use cases.

I think an option would be nice, which impose go default values, like Get...() 
does, instead of forcing everyone to use ugly pointer fields.

message A {
  optional int64 SomeIntField = 1 [careifset=no];
  optional B SomeBField = 2;
  optional C SomeCField = 3 [careifset=no];
}

message B {
  optional int64 SomeIntField = 1 [careifset=no];
  optional string SomeString = 2 [carifset=no];
}

message C {
  repeated B SomeArray = 1;
}

Maybe default can be used instead of careifset, which is not a thing at the 
moment.

Original comment by awalterschulze on 17 Jul 2012 at 2:05

[GoogleCodeExporter]

I'm not trying to spin pointers as positive, or anything else. I
realise their use here sucks. I'm merely explaining the design
decisions and, more importantly, constraints that led to their use.

We aren't going to change the use of pointers for fields.

Original comment by dsymo...@golang.org on 17 Jul 2012 at 10:08

[GoogleCodeExporter]

Thank you, this has been very helpful.

Unfortunately now I have work to do to make a custom solution, but I guess 
laziness can only get you so far. 

Original comment by awalterschulze on 18 Jul 2012 at 10:51