[protobuf] Re: Issue 59 in protobuf: Add another option to support java_implement_interface
Comment #14 on issue 59 by t.broyer: Add another option to support java_implement_interface http://code.google.com/p/protobuf/issues/detail?id=59 @kenton: neat idea! and it's not necessarily too late to add this as an alternate API to the existing writeTo/parseFrom/mergeFrom methods, to show the path to plugin developers. @aantono: a priori, there would be a need for 2 base interfaces: - for text formats, using Appendable and Readable (and String), and/or Writer and Reader - for binary formats, using OutputStream/InputStream (and ByteString, and/or byte[]). (BTW, I already knew protobuf-java-format, but it's based on the reflection API and is not "GWT-translatable" to JavaScript) -- You received this message because you are subscribed to the Google Groups "Protocol Buffers" group. To post to this group, send email to proto...@googlegroups.com. 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.
[protobuf] Re: Issue 59 in protobuf: Add another option to support java_implement_interface
Comment #13 on issue 59 by aantono: Add another option to support java_implement_interface http://code.google.com/p/protobuf/issues/detail?id=59 just an FYI, as its mentioned in issue 82, there is already a set of "formatters" for JSON, XML, etc, as part of the http://code.google.com/p/protobuf-java-format/ project. I've been toying around with an idea of making a common interface that they would all implement, so maybe then we could enhance the code generation part to accept any formatter/codec class which will be coded to a well- known interface. -- You received this message because you are subscribed to the Google Groups "Protocol Buffers" group. To post to this group, send email to proto...@googlegroups.com. 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.
[protobuf] Re: Issue 59 in protobuf: Add another option to support java_implement_interface
Comment #12 on issue 59 by ken...@google.com: Add another option to support
java_implement_interface
http://code.google.com/p/protobuf/issues/detail?id=59
For the alternate codec case, I think a better approach would be to
generate a
separate class to perform the encoding/decoding. E.g.:
interface JsonProtobufCodec {
String encode(T message);
T decode(String json);
}
Then in generated code:
class FooMessage {
...
// inserted by your plugin:
public static final JsonProtobufCodec JSON_CODEC =
new JsonProtobufCodec {
...
};
}
This requires that you pass the JSON codec object around together with your
protobuf
object, but this is not a terrible requirement in practice. I actually
wish that we
had designed the native format this way, rather than building it into the
class
itself, as it's more modular. Also, with this design, you could provide a
dynamic
implementation of JsonProtobufCodec which would work with DynamicMessage.
You could
also allow your code generator to work stand-alone, generating a separate
file,
allowing people to generate fast JSON codecs for protos whose code
generation they
don't control (e.g. descriptor.proto).
--
You received this message because you are subscribed to the Google Groups "Protocol
Buffers" group.
To post to this group, send email to proto...@googlegroups.com.
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.
[protobuf] Re: Issue 59 in protobuf: Add another option to support java_implement_interface
Comment #11 on issue 59 by t.broyer: Add another option to support java_implement_interface http://code.google.com/p/protobuf/issues/detail?id=59 Attached is a patch that adds insertion points (Java only) for code generator plugins. It uses a redundant but harmless "implements Message(Lite)" so that a plugin always inserts ", MyInterface" without risking conflict with another plugin (otherwise a plugin would have to know whether another has already inserted the "implements" keyword). My use case for resurrecting this issue is JSON or GWT-RPC ser/de-serialization (see issue 82 too) without using the reflection interface (for use in a "lite" environment or for "code speed") with polymorphism support. The only workaround is to patch your libprotobuf.jar by "augmenting" the MessageLite interface (but then you'd rather patch your protoc than write a code generator plugin too) Note that I do not have a C++ build environment, so I didn't even compile the patched code. Attachments: java_implements_insertion_point.patch 6.0 KB -- You received this message because you are subscribed to the Google Groups "Protocol Buffers" group. To post to this group, send email to proto...@googlegroups.com. 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.
