61–70 of 101 posts
I like the Go language because it's straightforward and clear, even if it looks a bit plain. I hope the feature mentioned in the article will cause a compiler error. However, I wouldn't use this approach when writing my own code.
golangci-lint run --enable-all --max-issues-per-linter=0 --max-same-issues=0
Earlier quoted context omitted.
I think that using embedding for discriminating unions if a good idea. It would work, but it does not force the user to do the discrimination. I would say that explicit typecasting at the point of discrimination is safer. Without it, nothing prevents you from using one field from one variant of the union, and another from a different variant. Introduction of proper discriminated unions would be great.
I'm not sure I understand you, or you understand me. I'm saying this is okay: type Order struct { Type OrderType CommonAttr1 int CommonAttr2 string } type OrderTypeA struct { Order TypeAAttr1 int TypeAAttr2 string } type OrderTypeB struct { Order TypeBAttr1 int TypeBAttr2 string } And yes you should convert to OrderTypeA or OrderTypeB at the first opportunity in domain code, and only convert from them at the latest o…
Go can only downcast through interfaces so there's something missing to your approach to unions, isn't there?
The same issue with embbedding of field had reflect tag like json or bson ...
Earlier quoted context omitted.
I'm not sure I understand you, or you understand me. I'm saying this is okay: type Order struct { Type OrderType CommonAttr1 int CommonAttr2 string } type OrderTypeA struct { Order TypeAAttr1 int TypeAAttr2 string } type OrderTypeB struct { Order TypeBAttr1 int TypeBAttr2 string } And yes you should convert to OrderTypeA or OrderTypeB at the first opportunity in domain code, and only convert from them at the latest o…
> And yes you should convert to OrderTypeA or OrderTypeB at the first opportunity in domain code, Go can only downcast through interfaces so there's something missing to your approach to unions, isn't there?
Who's actually expecting `xyz.com` here? Spec: https://go.dev/ref/spec#Selectors > x.f resolves to the field/method at the shallowest depth in T. If there isn’t exactly one at that depth, it’s illegal. Embedding promotes fields; on name collisions the shallowest wins. So `opts.URL` is `FooService.URL` (depth 1), not `BarConnectionOptions.URL` (depth 2).
Even given that it compiles, I wouldn’t exclude it being a runtime error.
But the big problem isn’t that it behaves as advertised, it’s that it is way too easy to write opts.URL where you mean opts.Bar.URL. Auto-complete will happily compete the wrong thing for you.
Over the course of ~10 years of writing Go, my ratio of "embedding a struct" to "regretting embedding a struct" is nearly 1:1. I do not embed structs anymore. It is almost always a mistake. I would confidently place it in the "you should be required to import 'unsafe' to use this feature" bin.
As long as these two aren't there, embedding structs is literally identical to dispatching methods, and can't be used for anything else due to lack of state management through it. You have to manage the states externally anyways from a memory ownership perspective.
Am I the only one who found the described behavior to be intuitively correct? I did expect it to print "abc.com".
I'm confused at the responses saying this intuitive. It's like saying: var x string x = "abc.com" x = "xyz.com" fmt.Println(x) will print abc.com and that's totally expected. The normal intuition would be that the latter operations or (re)definitions override the preceding ones.
The order of operations has nothing to do with it.
opts := Options{
FooService: FooService{URL: "abc.com"},
BarService: BarService{
BarConnectionOptions: BarConnectionOptions{
URL: "xyz.com",
},
},
}
opts := Options{
BarService: BarService{
BarConnectionOptions: BarConnectionOptions{
URL: "xyz.com",
},
},
FooService: FooService{URL: "abc.com"},
}