On Mon, Aug 21, 2017 at 9:38 AM, Henrik Johansson <dahankz...@gmail.com> wrote:
> I understand the the issue you are having. We had the same where we > differentiate between absent string and empty string. > It was messy with data from json but it worked. > > I think "int?", Optional or Maybe are not as helpful in Go as they can be > in Java or perhaps C# since a small type with custom marshalling can make > this safe when needed. > > That said, some standard way of denoting "absent" in cases with json or > protobuf (??) or xml would be nice. > How is this case catered to in for example gRPC? > In GRPC/protobuf, you use scalar values with syntax="proto2" (since that generates code that uses pointers, where nil means absent). For syntax="proto3", where absent and zero-value are intentionally indistinguishable, you would need to use a wrapper. Protobuf includes "well-known types" that wrap scalars. They are just boxes: a struct with a single scalar field (similar to Java's java.lang.Integer, for example) https://developers.google.com/protocol-buffers/docs/reference/google.protobuf (Int32Value, Int64Value, UInt32Value, UInt64Value, FloatValue, DoubleValue, BoolValue, and BytesValue) Fields of these types are represented as pointers to structs. If nil, the value is absent. If non-nil, the actual value is the single field of the target struct. > > > > > mån 21 aug. 2017 kl 15:24 skrev Tong Sun <suntong...@gmail.com>: > >> >> >> On Monday, August 21, 2017 at 3:44:41 AM UTC-4, Henry wrote: >> >> In my opinion, if you need a nullable type, you're entering a domain >>> problem. You are better off creating your own ADT (abstract data type) with >>> more descriptive names rather than "int?" or "float?". >> >> >> When we are talking about ADT, we are talking about extending the >> language itself. So I agree that it is a language problem, but do not agree >> it is a *domain only problem*, which is a polite way of saying, "that's >> your own problem, deal it yourself", because we've seen so many replies >> with so many suggestions and recommendations, i.e., just like what I >> suspected, you will see different people doing different things, which >> will be just like different people using different string implementation in >> C, and we end up with many C string libraries and implementations that are >> incompatible with each other. >> >> Again, whenever we are dealing with data, this (null situation) is >> inevitable. You are not suffering from the problem today do not mean that >> other people are not suffering, or you will never ever meet with it. >> I.e., in my view, it should be considered as part of the future Go. >> >> I do agree that there should be *more descriptive names rather than >> "int?" or "float?"*. That's why I only said "*like*" "int?", because >> there is no such name so far. >> >> -- >> You received this message because you are subscribed to the Google Groups >> "golang-nuts" group. >> To unsubscribe from this group and stop receiving emails from it, send an >> email to golang-nuts+unsubscr...@googlegroups.com. >> For more options, visit https://groups.google.com/d/optout. >> > -- > You received this message because you are subscribed to the Google Groups > "golang-nuts" group. > To unsubscribe from this group and stop receiving emails from it, send an > email to golang-nuts+unsubscr...@googlegroups.com. > For more options, visit https://groups.google.com/d/optout. > -- You received this message because you are subscribed to the Google Groups "golang-nuts" group. To unsubscribe from this group and stop receiving emails from it, send an email to golang-nuts+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/d/optout.
