search

google / protobuf.dart

Runtime library for Dart protobufs
https://pub.dev/packages/protobuf
BSD 3-Clause "New" or "Revised" License
527 stars 183 forks source link

Add support for Protobuf TextFormat #125

Open kriswuollett opened 6 years ago

kriswuollett commented 6 years ago

https://developers.google.com/protocol-buffers/docs/reference/cpp/google.protobuf.text_format

sigurdm commented 5 years ago

Does this include support for parsing the TextFormat?

If it is mainly for debugging purposes, the toString is relatively close to the textFormat.

kriswuollett commented 5 years ago

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.

osa1 commented 2 years ago

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 int, and the constants to interpret those ints (constants in field_type.dart) are not public.

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.

kriswuollett commented 2 years ago

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 text_format.h.

sigurdm commented 2 years ago

https://github.com/google/protobuf.dart/pull/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.

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)

osa1 commented 2 years ago

it can stay an int at be queried through getters

Which class do you add the getters to?

sigurdm commented 2 years ago

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 int-type currently (ok, it will probably not be getters, but functions of the tag-number).

We could also consider wrapping the type only for external use, and keep the int internally for performance...

osa1 commented 2 years ago

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 enum with all the proto field types) internally too, for example, in #592. Also in other (de)serialization code that check field types.

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.

osa1 commented 1 year ago

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