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.su...@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. <vidalborro...@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+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.
>

-- 
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