Apologies for the delay. I don't, but the basic sketch would be:
- define a custom option by extending google.protobuf.FieldOptions
- Implement a code generator that opens the files generated by the main
- Modify your build system to execute protoc with both the language specific
targets and your plugin:
protoc --cpp_out=. --your_plugin_out=.
(Likewise for other languages, or pass the list of languages to generate as
a parameter to your plugin in --your_plugin_out)
On Tue, Jul 12, 2011 at 6:25 AM, Bo Hansen <mdb...@gmail.com> wrote:
> Sounds interesting, do you have an example of doing this?
> On Jul 9, 2:21 am, Jason Hsueh <jas...@google.com> wrote:
> > Echoing Chris's messages, we don't really want to get into supporting
> > arbitrary types in the core implementation. Various language-specific
> > annotations could be added, but doing this portably across languages
> > be difficult. Supporting these types also complicate the reflection
> > implementations.
> > A fairly straightforward approach would be to use a custom option and
> > a plugin, keeping them as raw bytes on the wire. You could use the
> > class insertion points to insert wrapper methods that provide a
> > API around the field.
> > On Fri, Jul 8, 2011 at 5:06 PM, Christopher Smith <cbsm...@gmail.com>
> > > On Fri, Jul 8, 2011 at 9:46 AM, Eric Hopper <omnifari...@gmail.com>
> > > > I guess. This is an interesting and general problem. Practically
> > > > system like protobuf needs to solve it. Python itself, for example,
> > > > solves it for pickle by allowing you to write custom methods for your
> > > > classes to reduce them to well known types like tuples.
> > > That's a very different system, and a language specific solution. A
> > > lot of the success of protobufs is due to keeping the feature set very
> > > slim. Type aliasing adds a fair bit of complexity and really doesn't
> > > add much: you can always have common message types with locked in
> > > fields and code which knows how to transform those messages in to
> > > whatever representation your internal runtime has.
> > > Truth is, solutions like you are describing will have a lot of
> > > language specific issues, and I think it'd be hard to make a case for
> > > all that added effort. For many language, you don't need hooks in the
> > > library/generated code in order to handle this problem... others you
> > > need all kinds of work. At some point, you add all the "interesting
> > > and general" problems and protobufs start to look like ASN.1 or XML.
> > > ;-)
> > > > I don't think the custom translation can be avoided. But I do think
> > > > can be better integrated into the system.
> > > Modules seem like the logical way to do custom translations. Not sure
> > > what is wrong with that?
> > > > Protobuf's integer type can already represent integers of arbitrary
> > > > precision, it's just that not every language has an arbitrary
> > > > precision integer type. My idea would solve this problem by requiring
> > > > you to specify the (for example) C++ type to use when deserializing a
> > > > large integer. If you didn't, the protobuf compiler would generate an
> > > > error.
> > > In C++, you can accomplish this simply by overloading the conversion
> > > operator for whatever type you want that integer casted to, no? Yes it
> > > requires an intermediate state, but already having a mechanism to have
> > > custom transformations is going to cost you all kinds of performance
> > > optimization opportunities, so I don't feel there is much lost there.
> > > --
> > > Chris
> > > --
> > > You received this message because you are subscribed to the Google
> > > "Protocol Buffers" group.
> > > To post to this group, send email to firstname.lastname@example.org.
> > > 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 email@example.com.
> To unsubscribe from this group, send email to
> For more options, visit this group at
You received this message because you are subscribed to the Google Groups
"Protocol Buffers" group.
To post to this group, send email to firstname.lastname@example.org.
To unsubscribe from this group, send email to
For more options, visit this group at