Default values for required fields do mean that: use the default if not
explicitly set. This only affects the in-memory object, though -
IsInitialized() will still fail if a required field is not set. However,
such a proto would be usable by a client that does not do required field
checking by
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
On Wed, Aug 18, 2010 at 7:07 AM, Jeff Plaisance jeffplaisa...@gmail.comwrote:
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
All fields have default values. If no default is defined in the file, then
the default is zero/empty. So, hasX() only tells you whether or not the
field was explicitly set -- not whether or not it has a value (it always
does).
I understand that you might have a difference of taste here, but
I agree that defaults should be handled in the library. I have been putting
off the issue because i found the interaction between the hasX and getX
methods confusing when a default is specified. hasX returns false if x
isn't explicitly set, but getX may or may not return a valid value anyway
Hello,
I have written a compiler plugin that generates type safe scala
wrappers for the java protoc output. It creates wrappers for each
message type that use the scala Option type for all optional values.
It also forces all required parameters to be included in the
constructor of the builder so
Added to the wiki, thanks!
On Wed, Aug 11, 2010 at 12:57 AM, Jeff Plaisance jeffplaisa...@gmail.comwrote:
Hello,
I have written a compiler plugin that generates type safe scala
wrappers for the java protoc output. It creates wrappers for each
message type that use the scala Option type for
