Comments (13)
@tiancaiamao Go now supports oneof. We've written a reference document on how the Go protocol buffer compiler generates these, and how to use them: https://developers.google.com/protocol-buffers/docs/reference/go-generated#oneof
from protobuf.
We decided not to implement specific Go changes for oneof. It's a feature that simply doesn't fit well with Go.
from protobuf.
Should this be added to the README then? How do you recommend distinguishing between field values if they could all legitimately contain a zero value (say, where I would want to render the data in a web page)? e.g.
message Foo {
oneof value {
int64 int_val;
string string_val;
}
}
How would I distinguish:
Foo {int_val: 0}
from
Foo {string_val: ""}
AFAIK all the other supported languages would allow this distinction in some way or another?
from protobuf.
I would also like to know the answer to this.
from protobuf.
This looks like a problem - the value proposition of protocol buffers is that they are completely language-agnostic... This isn't a corner case, it's a component of the language specs that won't work on a language.
from protobuf.
Why not use empty interfaces and type switches here?
message Foo {
oneof value {
int64 int_val;
string string_val;
}
}
switch f := foo.(type) {
case int64:
// do stuff
case string:
// do stuff
}
This seems the the most idiomatic solution, and it prevents assigning multiple values concurrently.
from protobuf.
Whoa, that DOES sound like a pretty solid idea... So basically the oneof field would have a type interface{}
?
from protobuf.
Yeah. You lose some type safety (ie, you could assign anything to it), and I guess there's an edge case around multiple variants of the same type with different names.
from protobuf.
Yeah, that's true. It does assume that all subfields in the oneof have distinct types (which is probably the majority use case, but proto3 doesn't assert that it must be the case).
from protobuf.
We have a design that we're working through now. It's unfortunately more complicated than your suggestion out of necessity.
from protobuf.
Awesome! This is fantastic, thank you :).
Great design choice (tagged-union interface) btw. type-select casting looks very natural.
from protobuf.
AppEngine SDK has the old version of the package bundled; if you try to import github.com/golang/protobuf
it loads the old code without this commit even if you have the new code vendored in your project. I have manually downloaded this lib; copied it inside go_appengine/goroot/src; removed the old .a compiled file and goapp install github.com/golang/protobuf
to generate it again. Now it works correctly.
There is a simpler way of updating/vendoring protobuf in the AppEngine devserver?
from protobuf.
How far did we go now? Will it be supported in the future or never be supported?
I have a .proto file contain oneof, is there any temporary solution.
from protobuf.
Related Issues (20)
- Support for optional fields HOT 2
- Latest version of google.golang.org/protobuf (v1.33.0) is no longer compatible with the latest version of github.com/golang/protobuf (v1.5.3) HOT 7
- Add option to JSON marshal / unmarshal: StripEnumPrefix / AddEnumPrefix HOT 10
- How to properly define protobuf `oneof` fields? HOT 2
- How can I import a pre-compiled proto from another package? HOT 4
- protodesc: feature "message_encoding" (in Protobuf editions) triggers proto2 group validation checks HOT 11
- timestamppb.AsTime is incorrectly implemented for nil/zero values HOT 2
- missing replace in go.mod HOT 1
- protojson: fail to unmarshal JSON with reserved fields HOT 19
- Parsing protoc plugin option containing ',' HOT 5
- go_features.proto has incorrect package and error-prone file path HOT 5
- Tracking issue: Fully Lazy Extension decoding HOT 7
- feature: Generate test client / `bufconn` constructors HOT 4
- v1.33.0 breaks bazel build HOT 14
- Reflection: protopath parsing and path+message access HOT 7
- Proposal: Set go.mod Go language version to oldest supported Go version (1.21 currently) HOT 8
- Proposal: Add `Override` mode to `proto.Merge` HOT 2
- editions: maps are incorrectly serialized if file has default message encoding of DELIMITED HOT 8
- protodesc: too strict about proto3 field names when creating descriptors from FileDescriptorProto
- undefined: descriptorpb.Default_FileOptions_PhpGenericServices HOT 2
Recommend Projects
-
React
A declarative, efficient, and flexible JavaScript library for building user interfaces.
-
Vue.js
🖖 Vue.js is a progressive, incrementally-adoptable JavaScript framework for building UI on the web.
-
Typescript
TypeScript is a superset of JavaScript that compiles to clean JavaScript output.
-
TensorFlow
An Open Source Machine Learning Framework for Everyone
-
Django
The Web framework for perfectionists with deadlines.
-
Laravel
A PHP framework for web artisans
-
D3
Bring data to life with SVG, Canvas and HTML. 📊📈🎉
-
Recommend Topics
-
javascript
JavaScript (JS) is a lightweight interpreted programming language with first-class functions.
-
web
Some thing interesting about web. New door for the world.
-
server
A server is a program made to process requests and deliver data to clients.
-
Machine learning
Machine learning is a way of modeling and interpreting data that allows a piece of software to respond intelligently.
-
Visualization
Some thing interesting about visualization, use data art
-
Game
Some thing interesting about game, make everyone happy.
Recommend Org
-
Facebook
We are working to build community through open source technology. NB: members must have two-factor auth.
-
Microsoft
Open source projects and samples from Microsoft.
-
Google
Google ❤️ Open Source for everyone.
-
Alibaba
Alibaba Open Source for everyone
-
D3
Data-Driven Documents codes.
-
Tencent
China tencent open source team.
from protobuf.