Required fields having an explicit default do not affect serialization
but may affect how a language instantiates a message.
I wrote the Haskell version of protocol-buffers. And I used the "Maybe"
type constructor for "optional" fields. When serializing this means all
Nothing fields can be efficiently detected and omitted and when
de-serializing the omitted fields can be efficiently assigned Nothing.
There is a type class "MessageAPI" that provides uniform access to all
fields (including extension keys) with a "getVal" method. The
"MessageAPI" also defines an "isSet" test that returns True or False.
The getVal look for a (Just value) in the message, then an explicit
default (Just value) then uses the default-default value.
In writing this e-mail it has occurred to me that another API function
might be useful. A function that converted a message with optional
types to a message where there are no missing optional types. Perhaps
this would make a sibling Message type with all the "Maybe" removed, but
perhaps just using the same Message type and guaranteeing that there are
no Nothing entries would be useful enough. Hmmm....
On 03/09/2010 02:34, Jeff Plaisance wrote:
> Does default on required fields currently have a meaning? It compiles
> but I'm not sure if there are cases where the default is ever usable.
> Maybe required with default specified could mean use the default if not
> explicitly set. This change would also allow you to get rid of unused
> required fields over 2 releases. This might be too serious of an api
> change at this point, but it seems like required has fallen out of favor
> anyway, so maybe this wouldn't be too bad.
> On Tue, Aug 24, 2010 at 4:47 PM, Kenton Varda <ken...@google.com
> <mailto:ken...@google.com>> wrote:
> On Wed, Aug 18, 2010 at 7:07 AM, Jeff Plaisance
> <jeffplaisa...@gmail.com <mailto:jeffplaisa...@gmail.com>> wrote:
> It seems like the issue here is that optional has been
> overloaded to mean two different things:
> 1) Not really optional but in order to do rolling upgrades we're
> making it optional. The default should be used if it is not
> set. In my opinion, in this case there should be no "has"
> method because either its result is irrelevant or it is being
> used to overload some other meaning on top of optional.
> 2) Optional in the sense of Option, Maybe, Nullable, empty, can
> be null, whatever you want to call it. In my opinion this
> should be encapsulated in the type so that the programmer is
> forced to handle all possible cases. The has method should not
> be used for this because it is too easy to ignore.
> Yes, I think you're right, and I see how it makes sense to
> distinguish these two by the presence or absence of an explicit
> default value.
> You received this message because you are subscribed to the Google
> Groups "Protocol Buffers" group.
> To post to this group, send email to proto...@googlegroups.com.
> To unsubscribe from this group, send email to
> For more options, visit this group at
You received this message because you are subscribed to the Google Groups
"Protocol Buffers" group.
To post to this group, send email to proto...@googlegroups.com.
To unsubscribe from this group, send email to
For more options, visit this group at