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 <henner...@googlemail.com> 
>> wrote:
>>
>>> Hi,
>>> On Mon, Nov 30, 2009 at 15:16, dp <decimus...@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 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.

Reply via email to