-
Notifications
You must be signed in to change notification settings - Fork 185
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Add support for Protobuf TextFormat #125
Comments
Does this include support for parsing the TextFormat? If it is mainly for debugging purposes, the toString is relatively close to the textFormat. |
Yes, parsing and writing TextFormat. Not for debugging purposes. System I work on uses proto text for runtime configuration and human-readable data for creating test cases. |
We can't and don't want to support every alternative serialization format for protos. Ideally we should make it possible for users to implement (de)serializers as libraries. IIRC currently the only blocker for this is that we don't have a public protobuf field type. We expose field types as an Even if they were public, that API is painful to use and very error prone. #605 attempts to fix this, but it comes with runtime cost, because we currently don't have a way in Dart to implement zero-cost wrappers around existing types. Maybe something to revisit after view types. |
Feature request was generically for any type of support. Did not specifically request to be implemented on a message class. Implementation in a library should be fine as the package could have nearly identical methods as C++'s |
Even without zero-cost wrappers we could make a public interface for querying the field-type (it can stay an int at be queried through getters) |
Which class do you add the getters to? |
I guess from the FieldInfo where we currently expose We could also consider wrapping the type only for external use, and keep the int internally for performance... |
I considered this in #605, but I want to use this new class (actually I wonder if there's an implementation strategy where we introduce a type for external users only and then transparently start using it internally (maybe with view types when it's ready) without loss of performance and breaking downstream. |
In case we want to go ahead with this, the text format spec was made public a few weeks ago: https://developers.google.com/protocol-buffers/docs/text-format-spec |
https://developers.google.com/protocol-buffers/docs/reference/cpp/google.protobuf.text_format
The text was updated successfully, but these errors were encountered: