Re: [protobuf] Re: why protobuf optional field does not take null
Or you can use extension functions in Kotlin ;)
On Monday, March 20, 2017 at 12:53:43 PM UTC+1, Subin Sebastian wrote:
>
> 8 years later, still the only solution I have is,
>
> *class MyImprovedClass extends MyClass { // MyClass is protoc generated*
> *public void setOrClearFoo(String value) {*
> *if(value != null) setFoo(value);*
> *else clearFoo();*
> *}*
> *}*
>
> On Tuesday, December 1, 2009 at 7:04:26 AM UTC+5:30, Kenton Varda wrote:
>>
>> I'm still open to the idea of adding setOrClearFoo() methods that clear
>> the value if given null -- but only if it can be shown that this will not
>> significantly increase the size of compiled .class files.
>>
>> On Mon, Nov 30, 2009 at 3:42 PM, Henner Zeller
>> wrote:
>>
>>> Hi,
>>> On Mon, Nov 30, 2009 at 15:16, dp wrote:
>>> > Is this still true? Or is there some way to tell PB that a field can
>>> > potentially have null values?
>>>
>>> No change here.
>>>
>>> Problem is that 'null' and 'cleared' are semantically different things.
>>> Sometimes in the software world they're used to mean the same thing
>>> but protocol buffers shouldn't follow that, because that notion is not
>>> universal if you think platform independently. In C++ for instance,
>>> you won't deal with a 'NULL' string (unlike Java, no pointers, pardon,
>>> references are used there).
>>> Note, that protocol buffers have as well the notion of 'default
>>> values'. So if you set a field to 'null' but meaning to clear it, then
>>> accessing that field will return the default value. This is confusing
>>> at best.
>>>
>>> Given this and the platform independent notion I think it is better to
>>> be explicit and not have 'null' magically meaning clearing a field.
>>>
>>> > If not, any suggestions on how to deal with fields that could
>>> > potentially have null values? (Besides the obvious - don't set them,
>>> > d'oh)
>>> >
>>> > *Asking 'cuz I have a fairly big class (~100 fields) and testing if
>>> > each field is null before setting them in the PB Builder object is
>>> > somewhat of a pain.
>>>
>>> A one-line if (foo != null) b.setFoo(foo) else b.clearFoo(); might be
>>> a bit cluttersome sometimes. OTOH, it is pretty straightforward and
>>> quick to read.
>>>
>>> Maybe you can hack up some dynamic proxy that wraps around the setters
>>> (haven't done Java for some time, probably this only works with
>>> interfaces). Or alternatively you chaneg the higher level logic to
>>> just _not_ set a field instead of setting it to 'null' when it really
>>> means that it doesn't want to set it ...
>>>
>>> -h
>>>
>>> >
>>> > On Oct 29, 10:29 am, Kenton Varda wrote:
>>> >> Protocol buffers has no concept of null. Fields cannot be set to
>>> null. You
>>> >> can *clear* a field, like:
>>> >>
>>> >> builder.clearParamCountry();
>>> >>
>>> >> This sets the field back to its default value (the empty string,
>>> unless you
>>> >> declared some other default). Also, hasParamCountry() will return
>>> false
>>> >> until you set it to something else.
>>> >>
>>> >> But you cannot set any field to null -- this will throw a
>>> >> NullPointerException.
>>> >>
>>> >>
>>> >>
>>> >> On Thu, Oct 29, 2009 at 2:47 AM, micha
>>> wrote:
>>> >>
>>> >> > Hi,
>>> >>
>>> >> > I have a message with a optionl field.
>>> >>
>>> >> > * optional string param_country = 6;
>>> >>
>>> >> > I would like to avoid the to check each attribute if its null or
>>> not,
>>> >> > before setting it to the message.
>>> >>
>>> >> > In the net i found some code fragment of protobuf, that looked to me
>>> >> > that setting this field to null
>>> >>
>>> >> > * .setParamCountry(someNullReference)
>>> >>
>>> >> > makes the Builder to call clearParamCountry().
>>> >>
>>> >> > But I get a NullPoiterException
>>> >
>>> > --
>>> >
>>> > You received this message because you are subscribed to the Google
>>> Groups "Protocol Buffers" group.
>>> > To post to this group, send email to prot...@googlegroups.com.
>>> > To unsubscribe from this group, send email to
>>> protobuf+u...@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 prot...@googlegroups.com.
>>> To unsubscribe from this group, send email to
>>> protobuf+u...@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 unsubscribe from this group and stop receiving emails from it, send an email
to protobuf+unsubscr...@googlegroups.com.
To post to this group, send email to protobuf@googlegroups.com.
Visit this group at
Re: [protobuf] Re: why protobuf optional field does not take null
In a past life, we used a protoc plugin that just added these setOrClear*
to every builder for each non-repeated field (as well as getOrNull* methods
for every message). The standard generated java code has insertion points
that make this a fairly trivial plugin to write. We also experimented with
adding extra accessors/setters using Guava's Optional (and would probably
use Java 8's Optional today), but that just exploded the API too much.
The generated code is already so voluminous! Adding more and more cruft to
every generated proto wasn't awesome. However, I do agree that the
setOrClear* class of methods was the most useful. Without them, you can't
use method-chaining when building a message where one of the inputs you're
conveying is nullable.
// Kind of stinky:
MyMessage.Builder b = MyMessage.newBuilder()
.setFoo(foo)
.setBar(bar)
.setBaz(baz);
if (frobnitz != null) {
b.setFrobnitz(frobnitz)
}
return b.build();
// Better:
return MyMessage.newBuilder()
.setFoo(foo)
.setBar(bar)
.setBaz(baz)
.setOrClearFrobnitz(frobnitz)
.build();
*Josh Humphries*
jh...@bluegosling.com
On Mon, Mar 20, 2017 at 7:53 AM, Subin Sebastian
wrote:
> 8 years later, still the only solution I have is,
>
> *class MyImprovedClass extends MyClass { // MyClass is protoc generated*
> *public void setOrClearFoo(String value) {*
> *if(value != null) setFoo(value);*
> *else clearFoo();*
> *}*
> *}*
>
> On Tuesday, December 1, 2009 at 7:04:26 AM UTC+5:30, Kenton Varda wrote:
>>
>> I'm still open to the idea of adding setOrClearFoo() methods that clear
>> the value if given null -- but only if it can be shown that this will not
>> significantly increase the size of compiled .class files.
>>
>> On Mon, Nov 30, 2009 at 3:42 PM, Henner Zeller
>> wrote:
>>
>>> Hi,
>>> On Mon, Nov 30, 2009 at 15:16, dp wrote:
>>> > Is this still true? Or is there some way to tell PB that a field can
>>> > potentially have null values?
>>>
>>> No change here.
>>>
>>> Problem is that 'null' and 'cleared' are semantically different things.
>>> Sometimes in the software world they're used to mean the same thing
>>> but protocol buffers shouldn't follow that, because that notion is not
>>> universal if you think platform independently. In C++ for instance,
>>> you won't deal with a 'NULL' string (unlike Java, no pointers, pardon,
>>> references are used there).
>>> Note, that protocol buffers have as well the notion of 'default
>>> values'. So if you set a field to 'null' but meaning to clear it, then
>>> accessing that field will return the default value. This is confusing
>>> at best.
>>>
>>> Given this and the platform independent notion I think it is better to
>>> be explicit and not have 'null' magically meaning clearing a field.
>>>
>>> > If not, any suggestions on how to deal with fields that could
>>> > potentially have null values? (Besides the obvious - don't set them,
>>> > d'oh)
>>> >
>>> > *Asking 'cuz I have a fairly big class (~100 fields) and testing if
>>> > each field is null before setting them in the PB Builder object is
>>> > somewhat of a pain.
>>>
>>> A one-line if (foo != null) b.setFoo(foo) else b.clearFoo(); might be
>>> a bit cluttersome sometimes. OTOH, it is pretty straightforward and
>>> quick to read.
>>>
>>> Maybe you can hack up some dynamic proxy that wraps around the setters
>>> (haven't done Java for some time, probably this only works with
>>> interfaces). Or alternatively you chaneg the higher level logic to
>>> just _not_ set a field instead of setting it to 'null' when it really
>>> means that it doesn't want to set it ...
>>>
>>> -h
>>>
>>> >
>>> > On Oct 29, 10:29 am, Kenton Varda wrote:
>>> >> Protocol buffers has no concept of null. Fields cannot be set to
>>> null. You
>>> >> can *clear* a field, like:
>>> >>
>>> >> builder.clearParamCountry();
>>> >>
>>> >> This sets the field back to its default value (the empty string,
>>> unless you
>>> >> declared some other default). Also, hasParamCountry() will return
>>> false
>>> >> until you set it to something else.
>>> >>
>>> >> But you cannot set any field to null -- this will throw a
>>> >> NullPointerException.
>>> >>
>>> >>
>>> >>
>>> >> On Thu, Oct 29, 2009 at 2:47 AM, micha
>>> wrote:
>>> >>
>>> >> > Hi,
>>> >>
>>> >> > I have a message with a optionl field.
>>> >>
>>> >> > * optional string param_country = 6;
>>> >>
>>> >> > I would like to avoid the to check each attribute if its null or
>>> not,
>>> >> > before setting it to the message.
>>> >>
>>> >> > In the net i found some code fragment of protobuf, that looked to me
>>> >> > that setting this field to null
>>> >>
>>> >> > * .setParamCountry(someNullReference)
>>> >>
>>> >> > makes the Builder to call clearParamCountry().
>>> >>
>>> >> > But I get a NullPoiterException
>>> >
>>> > --
>>> >
>>> > You received this message
Re: [protobuf] Re: why protobuf optional field does not take null
8 years later, still the only solution I have is,
*class MyImprovedClass extends MyClass { // MyClass is protoc generated*
*public void setOrClearFoo(String value) {*
*if(value != null) setFoo(value);*
*else clearFoo();*
*}*
*}*
On Tuesday, December 1, 2009 at 7:04:26 AM UTC+5:30, Kenton Varda wrote:
>
> I'm still open to the idea of adding setOrClearFoo() methods that clear
> the value if given null -- but only if it can be shown that this will not
> significantly increase the size of compiled .class files.
>
> On Mon, Nov 30, 2009 at 3:42 PM, Henner Zeller > wrote:
>
>> Hi,
>> On Mon, Nov 30, 2009 at 15:16, dp
>> wrote:
>> > Is this still true? Or is there some way to tell PB that a field can
>> > potentially have null values?
>>
>> No change here.
>>
>> Problem is that 'null' and 'cleared' are semantically different things.
>> Sometimes in the software world they're used to mean the same thing
>> but protocol buffers shouldn't follow that, because that notion is not
>> universal if you think platform independently. In C++ for instance,
>> you won't deal with a 'NULL' string (unlike Java, no pointers, pardon,
>> references are used there).
>> Note, that protocol buffers have as well the notion of 'default
>> values'. So if you set a field to 'null' but meaning to clear it, then
>> accessing that field will return the default value. This is confusing
>> at best.
>>
>> Given this and the platform independent notion I think it is better to
>> be explicit and not have 'null' magically meaning clearing a field.
>>
>> > If not, any suggestions on how to deal with fields that could
>> > potentially have null values? (Besides the obvious - don't set them,
>> > d'oh)
>> >
>> > *Asking 'cuz I have a fairly big class (~100 fields) and testing if
>> > each field is null before setting them in the PB Builder object is
>> > somewhat of a pain.
>>
>> A one-line if (foo != null) b.setFoo(foo) else b.clearFoo(); might be
>> a bit cluttersome sometimes. OTOH, it is pretty straightforward and
>> quick to read.
>>
>> Maybe you can hack up some dynamic proxy that wraps around the setters
>> (haven't done Java for some time, probably this only works with
>> interfaces). Or alternatively you chaneg the higher level logic to
>> just _not_ set a field instead of setting it to 'null' when it really
>> means that it doesn't want to set it ...
>>
>> -h
>>
>> >
>> > On Oct 29, 10:29 am, Kenton Varda wrote:
>> >> Protocol buffers has no concept of null. Fields cannot be set to
>> null. You
>> >> can *clear* a field, like:
>> >>
>> >> builder.clearParamCountry();
>> >>
>> >> This sets the field back to its default value (the empty string,
>> unless you
>> >> declared some other default). Also, hasParamCountry() will return
>> false
>> >> until you set it to something else.
>> >>
>> >> But you cannot set any field to null -- this will throw a
>> >> NullPointerException.
>> >>
>> >>
>> >>
>> >> On Thu, Oct 29, 2009 at 2:47 AM, micha
>> wrote:
>> >>
>> >> > Hi,
>> >>
>> >> > I have a message with a optionl field.
>> >>
>> >> > * optional string param_country = 6;
>> >>
>> >> > I would like to avoid the to check each attribute if its null or not,
>> >> > before setting it to the message.
>> >>
>> >> > In the net i found some code fragment of protobuf, that looked to me
>> >> > that setting this field to null
>> >>
>> >> > * .setParamCountry(someNullReference)
>> >>
>> >> > makes the Builder to call clearParamCountry().
>> >>
>> >> > But I get a NullPoiterException
>> >
>> > --
>> >
>> > You received this message because you are subscribed to the Google
>> Groups "Protocol Buffers" group.
>> > To post to this group, send email to prot...@googlegroups.com
>> .
>> > To unsubscribe from this group, send email to
>> protobuf+u...@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 prot...@googlegroups.com
>> .
>> To unsubscribe from this group, send email to
>> protobuf+u...@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 unsubscribe from this group and stop receiving emails from it, send an email
to protobuf+unsubscr...@googlegroups.com.
To post to this group, send email to protobuf@googlegroups.com.
Visit this group at https://groups.google.com/group/protobuf.
For more options, visit https://groups.google.com/d/optout.
[protobuf] Re: why protobuf optional field does not take null
Is this still true? Or is there some way to tell PB that a field can potentially have null values? If not, any suggestions on how to deal with fields that could potentially have null values? (Besides the obvious - don't set them, d'oh) *Asking 'cuz I have a fairly big class (~100 fields) and testing if each field is null before setting them in the PB Builder object is somewhat of a pain. On Oct 29, 10:29 am, Kenton Varda ken...@google.com wrote: Protocol buffers has no concept of null. Fields cannot be set to null. You can *clear* a field, like: builder.clearParamCountry(); This sets the field back to its default value (the empty string, unless you declared some other default). Also, hasParamCountry() will return false until you set it to something else. But you cannot set any field to null -- this will throw a NullPointerException. On Thu, Oct 29, 2009 at 2:47 AM, micha mherttr...@googlemail.com wrote: Hi, I have a message with a optionl field. * optional string param_country = 6; I would like to avoid the to check each attribute if its null or not, before setting it to the message. In the net i found some code fragment of protobuf, that looked to me that setting this field to null * .setParamCountry(someNullReference) makes the Builder to call clearParamCountry(). But I get a NullPoiterException -- 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.
Re: [protobuf] Re: why protobuf optional field does not take null
Hi, On Mon, Nov 30, 2009 at 15:16, dp decimusphos...@gmail.com wrote: Is this still true? Or is there some way to tell PB that a field can potentially have null values? No change here. Problem is that 'null' and 'cleared' are semantically different things. Sometimes in the software world they're used to mean the same thing but protocol buffers shouldn't follow that, because that notion is not universal if you think platform independently. In C++ for instance, you won't deal with a 'NULL' string (unlike Java, no pointers, pardon, references are used there). Note, that protocol buffers have as well the notion of 'default values'. So if you set a field to 'null' but meaning to clear it, then accessing that field will return the default value. This is confusing at best. Given this and the platform independent notion I think it is better to be explicit and not have 'null' magically meaning clearing a field. If not, any suggestions on how to deal with fields that could potentially have null values? (Besides the obvious - don't set them, d'oh) *Asking 'cuz I have a fairly big class (~100 fields) and testing if each field is null before setting them in the PB Builder object is somewhat of a pain. A one-line if (foo != null) b.setFoo(foo) else b.clearFoo(); might be a bit cluttersome sometimes. OTOH, it is pretty straightforward and quick to read. Maybe you can hack up some dynamic proxy that wraps around the setters (haven't done Java for some time, probably this only works with interfaces). Or alternatively you chaneg the higher level logic to just _not_ set a field instead of setting it to 'null' when it really means that it doesn't want to set it ... -h On Oct 29, 10:29 am, Kenton Varda ken...@google.com wrote: Protocol buffers has no concept of null. Fields cannot be set to null. You can *clear* a field, like: builder.clearParamCountry(); This sets the field back to its default value (the empty string, unless you declared some other default). Also, hasParamCountry() will return false until you set it to something else. But you cannot set any field to null -- this will throw a NullPointerException. On Thu, Oct 29, 2009 at 2:47 AM, micha mherttr...@googlemail.com wrote: Hi, I have a message with a optionl field. * optional string param_country = 6; I would like to avoid the to check each attribute if its null or not, before setting it to the message. In the net i found some code fragment of protobuf, that looked to me that setting this field to null * .setParamCountry(someNullReference) makes the Builder to call clearParamCountry(). But I get a NullPoiterException -- 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. -- 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.
[protobuf] Re: why protobuf optional field does not take null
Protocol buffers has no concept of null. Fields cannot be set to null. You can *clear* a field, like: builder.clearParamCountry(); This sets the field back to its default value (the empty string, unless you declared some other default). Also, hasParamCountry() will return false until you set it to something else. But you cannot set any field to null -- this will throw a NullPointerException. On Thu, Oct 29, 2009 at 2:47 AM, micha mherttr...@googlemail.com wrote: Hi, I have a message with a optionl field. * optional string param_country = 6; I would like to avoid the to check each attribute if its null or not, before setting it to the message. In the net i found some code fragment of protobuf, that looked to me that setting this field to null * .setParamCountry(someNullReference) makes the Builder to call clearParamCountry(). But I get a NullPoiterException --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups Protocol Buffers group. To post to this group, send email to protobuf@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 -~--~~~~--~~--~--~---
