To restate and generalize what others have said:
Default values have one purpose: they define what is returned by a field's
getter if the field is not set. The meaning applies equally to required and
optional fields. That's it. The default value simply does not affect
anything except for the g
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 usin
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 effic
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 field
On Wed, Aug 18, 2010 at 7:07 AM, Jeff Plaisance 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
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 ei
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 note
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
depe
I'd actually argue, perhaps counter-intuitively, that you don't want to use
Option for optional fields. Instead, the model in protocol buffers is to
return the default value if the field is not set, and have another method to
query whether the field was explicitly set. It is considered good style
Added to the wiki, thanks!
On Wed, Aug 11, 2010 at 12:57 AM, Jeff Plaisance wrote:
> 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 value
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
11 matches
Mail list logo
