Add support for Protobuf TextFormat

[kriswuollett]

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

[sigurdm]

Does this include support for parsing the TextFormat?

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

[kriswuollett]

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]

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]

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]

#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]

it can stay an int at be queried through getters

Which class do you add the getters to?

[sigurdm]

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]

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]

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