search

plutoo / protobuf-csharp-port

Automatically exported from code.google.com/p/protobuf-csharp-port
Other
0 stars 0 forks source link

Feature: add support for Decimal type #78

Closed GoogleCodeExporter closed 9 years ago

GoogleCodeExporter commented 9 years ago 
Consider the following message:

message Purchase {
  optional bytes amount = 1 [(csharp_type) = CSharpTypes.DECIMAL];
}

Generated code should look like:

class Purchase {
  public Decimal Amount {...};
}

Serialization wise, it would be seen as a sequence of bytes.

Original issue reported on code.google.com by igorga...@gmail.com on 21 Feb 2014 at 2:42

GoogleCodeExporter commented 9 years ago 
[deleted comment]
GoogleCodeExporter commented 9 years ago 
[deleted comment]
GoogleCodeExporter commented 9 years ago 
[deleted comment]
GoogleCodeExporter commented 9 years ago 
Patch: 
https://github.com/igorgatis/protobuf-csharp-port/compare/issue78?expand=1

Original comment by igorga...@gmail.com on 24 Mar 2014 at 6:10

GoogleCodeExporter commented 9 years ago 
I'm not sure about this one - in particular, I'd want to make sure that it at 
least interoperates with ProtoBuf.NET. While it would definitely be nice to 
have support for decimal, I don't want to rush into it. I'll keep this open for 
now, and take a closer look at the patch.

Original comment by jonathan.skeet on 5 Apr 2014 at 3:01

GoogleCodeExporter commented 9 years ago 
Sounds fair.

In terms of wire format, it works just fine. The decimal field is represented 
as a proto message.

In terms of text format uses string to represent Decimal field. That's not 
compatible with other PB implementations. But it can be changed to produce both 
human friendly or TextFormat.Merge() friendly formats.

I agree adding support for that is a big commitment. Perhaps I can keep this 
fork in sync and people can fallback to my implementation if they are OK with 
the drawbacks.

Original comment by igorga...@gmail.com on 7 Apr 2014 at 3:31

GoogleCodeExporter commented 9 years ago 
Closing as won't fix, as I don't think that going for a C#-specific approach is 
a good idea for this. We should be looking at common types to be shared across 
multiple platforms, with a common representation.

Original comment by jonathan.skeet on 15 Feb 2015 at 5:26