Override ToString behavior in ProtoBuf 3 C# implementation

[Teddy Zhang]

I need to override the ToString behavior in C# to make it human readable.

E.g. I defined a message type to represent DateTime in C#, and then write a partial class to make it be able to convert from/to DateTime.

message ProtoDateTime

{

     sfixed64 BinaryData = 1;

}

However, the default ToString() doesn't generate human readable contents.

Currently the default implantation is (codegen code):

public override string ToString() {

return pb::JsonFormatter.Default.Format(this);

}

Which will generate something like this, which is not readable.

{ "dateTime": { "binaryData": "5247507155853679530" } }

Is there a way to override this behavior?

If not, is there a plan to support this? Thanks.

[Teddy Zhang]

+Jon who seems to be the developer on this.

[Jon Skeet]

Hmm... I posted a reply to this yesterday, but apparently it didn't make it through. Let's see if this one gets through to the group.

I've raised an issue for it on Github, but don't have any plans to support it imminently.

I would strongly urge you away from your current platform-specific DateTime representation. If you can, use the Timestamp well-known type, which has a custom Json representation. If not, consider another platform-neutral representation which is likely to be more readable in a string form anyway. (DateTime is somewhat broken as a type anyway. When Noda Time 2.0 is out, I intend to create another Nuget package to bridge that and Protobuf. The choice of nanosecond precision in Noda Time 2.0 was influenced by proto3.)

Jon

[Teddy]

Thanks for the info on Noda Time. I'll consider using Noda Time when we move to proto 3.

The issue here is actually creating custom message for common types like the DateTime above (which seems to be a poor example). Other common types we need are guid, timespan, unix time etc. We want to have a user friendly representation in debugger/logs for easier debugging/troubleshooting.

[Jon Skeet]

The C# codegen only works for proto3 anyway.

Out of your examples, I'd use Duration and Timestamp - and probably just a string for Guid. That's the one I'd be most convinced by though, as the difference in storage between the text and binary representation is so high. Note that this would only be for diagnostic purposes though - the Json formatter and parser will not use it.

(I don't know whether any other platforms support this, mind you...)

Jon

[Jon Skeet]

The Github issue is this one, by the way:

https://github.com/google/protobuf/issues/933

Note that an alternative for debugging would be to use a DebuggerDisplayAttribute applied on the partial class. Haven't tried this myself, but will look into it.

Jon

[Jon Skeet]

Firstly, I'd encourage you not to do that:

a) this opaque binary data goes against the general aims of protos being cross-platform. That may not be a requirement for you at the moment, but I'd urge you to at least bear it in mind

b) unless you really need DateTime's somewhat odd semantics (http://blog.nodatime.org/2011/08/what-wrong-with-datetime-anyway.html) I'd encourage you to use the well-known Timestamp type. There are conversions available within that already, and it has a custom format which is basically ISO-8601.

As an aside, at some point after Noda Time 2.0 has landed, I expect to create a NodaTime.Protobuf nuget package which adds conversions between Instant and Timestamp, and NodaTime.Duration and Google.Protobuf.WellKnownTypes.Duration too. The nanosecond precision in protobuf was a contributing factor to the decision to use nanosecond precision in Noda Time 2.0. Just something to bear in mind if you were already considering Noda Time.

Now, all that aside, I can see cases where it might make sense. I've filed https://github.com/google/protobuf/issues/933 to capture this, partly so that others could add their use cases to it. The proposed way of implementing it would be a somewhat grotty hack though, using a partial method with a ref parameter. Other ideas would be welcome...

Jon