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 that people are likely to assume that adding or removing a default declaration in a .proto file is a source-compatible change, since this is the case in the reference implementations. This may mean that users of your Scala version find their builds breaking more often. Up to you if you feel like that's a worthwhile trade-off. On Tue, Aug 17, 2010 at 10:51 PM, Jeff Plaisance <jeffplaisa...@gmail.com>wrote: > 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.
