and these hazzers logics have to go away.
Google says, we will continue to support proto2 for a long time.
True, but it also means that if we ever want to use proto3 features (which
we do), then we have to trade away presence logic for primitive fields.
This is an unfortunate
We happen to use the protobuf-dt https://code.google.com/p/protobuf-dt/
plugin for Eclipse. The project (open-source) is owned by two Google
engineers, but it hasn't been updated in a while - it *really* needs to be
updated. It can be configured to compile your .proto files (using
protoc.exe)
Open question to everyone. I'm curious.
In all of your use-cases with protobuf, how often do you find yourself
using has_foo() (a.k.a. hazzers) for primitive fields? We use them
almost everywhere because, for example, it is a very useful way of
error-checking requests on the server sent from
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
In this context, it's the Parameter Object
Patternhttp://refactoring.com/catalog/introduceParameterObject.html
.
I am pushing our team toward doing this *exact* thing for our client-side
library (Android, iOS, WP8, Javascript). The only objection that I keep
hearing from team members is that
Greetings all,
We are using version 2.5. What is the most efficient way (*i.e.* single
copy operation, no extra byte arrays) to construct a ByteString from a
specific number of bytes in an InputStream? The various versions of
ByteString.readFrom() drain the stream completely, which is not
Hi Feng Xiao! Thanks for the response.
That's actually our backup plan. We were hoping to avoid it, though,
since the wrappers would each contain an extra copy of the data internally.
Our ideal case is for the data to get copied in a single step directly from
an InputStream to a ByteString
... Actually, I just now took a closer look at the readChunk() method. Even
that method makes an internal copy, so it looks like readChunk() isn't what
we are looking for after all. Hmmm.
On Tuesday, August 6, 2013 12:28:56 AM UTC-4, V.B. wrote:
Hi Feng Xiao! Thanks for the response
+1
I run a project where data is passed between Android, iOS, and Windows
Phone 8, with an AppEngine backend and a GWT frontend. We absolutely love
using protocol buffers, but the glaring hangup we keep running into is the
lack of an iOS PB compiler. (That, and GWT doesn't have protocol buffer
