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
depending on whether or not there is a default value.  I feel that this may
lead to bugs where the programmer checks hasX and assumes x is not set
although there is a valid default.  I have changed scala-protobuf so that if
a default is specified it is used instead of Option.  This is really easy to
do using scala 2.8's new named parameters, which i hadn't noticed when i
first wrote this.  I still think that Option is the right choice if there is
no default, as it forces the programmer to handle the case where it is not
set.

Jeff

On Tue, Aug 17, 2010 at 6:42 PM, Kenton Varda <ken...@google.com> wrote:

> 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 to
> design protocols such that the latter method never has to be called.
>
> Note that many people -- myself included -- advocate never declaring any
> field "required" because it almost always turns out that there is some use
> case for your message where the field isn't actually required, and you can
> never change "required" to "optional" later without risking breaking
> something.  It sounds like your implementation would actually encourage
> people to use "required" to avoid having to deal with Option objects.
>
> On Wed, Aug 11, 2010 at 12:57 AM, Jeff Plaisance 
> <jeffplaisa...@gmail.com>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 values.
>> It also forces all required parameters to be included in the
>> constructor of the builder so that calling build will never throw an
>> exception.
>>
>> here is a link to the repository:
>> http://github.com/jeffplaisance/scala-protobuf
>>
>> here is a short description of the output:
>>
>> http://wiki.github.com/jeffplaisance/scala-protobuf/what-you-get-from-scala-protobuf
>>
>> Jeff
>>
>> --
>> 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
>> protobuf+unsubscr...@googlegroups.com<protobuf%2bunsubscr...@googlegroups.com>
>> .
>> For more options, visit this group at
>> http://groups.google.com/group/protobuf?hl=en.
>>
>>
>

-- 
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 
protobuf+unsubscr...@googlegroups.com.
For more options, visit this group at 
http://groups.google.com/group/protobuf?hl=en.

Reply via email to