On Thu Jan 22 2015 at 4:53:53 PM <gtw.gt...@gmail.com> wrote:

>
> As a new user, we still have need (C++ target) for default values, as well
> as  required fields (e.g., message headers for embedded target).
>
> 1) It appears that you are completely removing the default/required
> capability from the proto3 language.  Is this correct ?
>
Yes.


> 2) Will the proto2 language be maintained going forward ?
>
Yes. Proto2 will continue to be supported for C++/Java/Python. The new
languages that we are adding may only support proto3 though.


> If so, then a simple generation addition may work for the envisioned
> application.  This is to generate non-static default message content so
> that the copy operator works simply, enabling applications to populate
>     changed fields with minimal coding effort.  I looked into this
> possibility before I saw this forum thread.
>
> Thank you for your effort and reply.
>
> Gilbert T Williams.
>
>
>
> On Wednesday, January 21, 2015 at 2:33:59 PM UTC-5, Feng Xiao wrote:
>
>> The proto3 design discussion has lasted for more than half a year and all
>> of them happened as an internal process. We have a lot of design docs,
>> email exchanges and weekly design meetings, but they are not available for
>> public consumption. Currently we are preparing public documentations for
>> proto3 and it's targeted to be publicized late this quarter.
>>
>> On Wed Jan 21 2015 at 6:00:35 AM Sumit Kumar <kumar...@hotmail.com>
>> wrote:
>>
> Specially makes difficult for adoption in financial applications, the
>>> has_field was one of the key reasons to migrate over to protofuf.
>>>
>>> Financial applications need differentiation in-between 0 value set and
>>> not set. Eg: Limit order with 0 price is valid but with no price set is
>>> invalid. Likewise market order with no price set is valid and with any
>>> other price set is invalid (including the 0 value). And there are many
>>> other cases, but anyway if the decision is made then not much value
>>> discussing it.
>>>
>>> Regards,
>>> Sumit Kumar
>>>
>>
>>> On 17 Jan 2015, at 10:52 am, V.B. <vidalb...@gmail.com> wrote:
>>>
>>> I suppose what I'm really wondering is:
>>> a) How does it simplify the language implementations exactly?
>>> b) Why was that not the case for *non*-primitives, which still have
>>> presence logic?
>>>
>>>
>>> On Friday, January 16, 2015 at 6:39:56 PM UTC-5, Feng Xiao wrote:
>>>>
>>>> The reason for dropping field presence is more of the same with
>>>> dropping default values. Basically we want to simplify protobuf and make it
>>>> easier to implement efficiently in more languages. We are preparing the
>>>> proto3 documentation and will share more information about the trade-offs
>>>> we have made.
>>>> On Fri Jan 16 2015 at 12:17:25 PM V.B. <vidalb...@gmail.com> wrote:
>>>>
>>>>> Can I ask for more details about why presence logic was removed (e.g.
>>>>> hasFoo() ) for primitives? This has been a very useful feature for us.
>>>>>
>>>>>
>>>>>       1. Removal of field presence logic for primitive value fields,
>>>>>> removal
>>>>>>          of required fields, and removal of default values. This
>>>>>> makes proto3
>>>>>>          significantly easier to implement with open struct
>>>>>> representations,
>>>>>>          as in languages like Android Java, Objective C, or Go.
>>>>>>
>>>>>  --
>>>>> 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+u...@googlegroups.com.
>>>>> To post to this group, send email to prot...@googlegroups.com.
>>>>> Visit this group at http://groups.google.com/group/protobuf.
>>>>> For more options, visit https://groups.google.com/d/optout.
>>>>>
>>>>  --
>>> 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+u...@googlegroups.com.
>>> To post to this group, send email to prot...@googlegroups.com.
>>> Visit this group at http://groups.google.com/group/protobuf.
>>> For more options, visit https://groups.google.com/d/optout.
>>>
>>>  --
>>> 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+u...@googlegroups.com.
>>> To post to this group, send email to prot...@googlegroups.com.
>>> Visit this group at http://groups.google.com/group/protobuf.
>>> For more options, visit https://groups.google.com/d/optout.
>>>
>>  --
> 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 http://groups.google.com/group/protobuf.
> For more options, visit https://groups.google.com/d/optout.
>

-- 
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 http://groups.google.com/group/protobuf.
For more options, visit https://groups.google.com/d/optout.

Reply via email to