Why default values instead of Option

440 views
Skip to first unread message

Jeroen Gordijn

unread,
Jan 30, 2017, 9:39:34 AM1/30/17
to ScalaPB
Hi,

I'm trying to upgrade from scalapb 0.4.21 to the new sbt-protoc with compilerplugin. I see that the fields in my proto3 file now get a default value instead of being an Option. Why is this changed? Am I missing something?

The documentation (https://scalapb.github.io/generated-code.html) states that "optional" fields are wrapped in an Option, but this example is for proto2. In an earlier page (https://scalapb.github.io/sbt-settings.html) of the documentation it states that proto3 is now the default.

There is certainly a difference between leaving a field blank and setting an int field to 0, but I see no way to make this distinction in my code. Also, I'm under the impression that if I set an int field to 0 it will not be written in the binary message. Is this true and if so, doesn't this break the interoperability with other compilers?

Please tell me if I'm missing something, or what the background of this change is.

Thanks in advance.
Cheers,
Jeroen

Nadav Samet

unread,
Jan 30, 2017, 10:37:12 AM1/30/17
to Jeroen Gordijn, ScalaPB
Hi Jeroen,

0.4.x wasn't designed to work with proto3, so whatever got generated for proto3 by 0.4.x was unintended. In proto3, there is no distinction between leaving a field blank and setting  it to zero (or empty string, etc) - see https://developers.google.com/protocol-buffers/docs/proto3#default. In both cases it doesn't get serialized in the wire format, and when you deserialize you can't tell if it was unset or explicitly set to zero. Therefore, there isn't enough data to use Option, you can just have the value itself.

Proto3 parsers/serializers also work in exactly the same way, so there is no interoperability issues. If you really want to keep the Options, you have a few options :) :
1. consider using primitive wrappers (see https://scalapb.github.io/customizations.html), though this changes the binary representation (can't just change existing messages).
2. use custom types (see https://scalapb.github.io/customizations.html) and create a TypeMapper[Int, Option[Int]] etc. 
3. downgrade your schema to proto2 (but stay on the 0.5.x ScalaPB branch)

-Nadav 


--
You received this message because you are subscribed to the Google Groups "ScalaPB" group.
To unsubscribe from this group and stop receiving emails from it, send an email to scalapb+unsubscribe@googlegroups.com.
To post to this group, send email to sca...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/scalapb/da659db7-d4de-4889-b281-87094b3fbd5c%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.



--
-Nadav

Jeroen Gordijn

unread,
Jan 30, 2017, 10:42:55 AM1/30/17
to ScalaPB, jeroen....@gmail.com
Hi Nadav,

Thanks for the quick reply. I was not aware that this is the way protobuf itself works. I will reconsider my options.

Thanks,
Jeroen

Op maandag 30 januari 2017 16:37:12 UTC+1 schreef Nadav Samet:
Hi Jeroen,

0.4.x wasn't designed to work with proto3, so whatever got generated for proto3 by 0.4.x was unintended. In proto3, there is no distinction between leaving a field blank and setting  it to zero (or empty string, etc) - see https://developers.google.com/protocol-buffers/docs/proto3#default. In both cases it doesn't get serialized in the wire format, and when you deserialize you can't tell if it was unset or explicitly set to zero. Therefore, there isn't enough data to use Option, you can just have the value itself.

Proto3 parsers/serializers also work in exactly the same way, so there is no interoperability issues. If you really want to keep the Options, you have a few options :) :
1. consider using primitive wrappers (see https://scalapb.github.io/customizations.html), though this changes the binary representation (can't just change existing messages).
2. use custom types (see https://scalapb.github.io/customizations.html) and create a TypeMapper[Int, Option[Int]] etc. 
3. downgrade your schema to proto2 (but stay on the 0.5.x ScalaPB branch)

-Nadav 


On Mon, Jan 30, 2017 at 6:39 AM, Jeroen Gordijn <jeroen....@gmail.com> wrote:
Hi,

I'm trying to upgrade from scalapb 0.4.21 to the new sbt-protoc with compilerplugin. I see that the fields in my proto3 file now get a default value instead of being an Option. Why is this changed? Am I missing something?

The documentation (https://scalapb.github.io/generated-code.html) states that "optional" fields are wrapped in an Option, but this example is for proto2. In an earlier page (https://scalapb.github.io/sbt-settings.html) of the documentation it states that proto3 is now the default.

There is certainly a difference between leaving a field blank and setting an int field to 0, but I see no way to make this distinction in my code. Also, I'm under the impression that if I set an int field to 0 it will not be written in the binary message. Is this true and if so, doesn't this break the interoperability with other compilers?

Please tell me if I'm missing something, or what the background of this change is.

Thanks in advance.
Cheers,
Jeroen

--
You received this message because you are subscribed to the Google Groups "ScalaPB" group.
To unsubscribe from this group and stop receiving emails from it, send an email to scalapb+u...@googlegroups.com.

To post to this group, send email to sca...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/scalapb/da659db7-d4de-4889-b281-87094b3fbd5c%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.



--
-Nadav
Reply all
Reply to author
Forward
0 new messages