11–20 of 101 posts
That’s actually crazy. Why is this even a feature?
At risk of being excessively sassy this looks like a case of wanting the ergonomics of multiple inheritance without fully grappling with the complexities or implications of it.
That’s actually crazy. Why is this even a feature?
That’s actually crazy. Why is this even a feature?
[1] http://doc.cat-v.org/plan_9/4th_edition/papers/comp, look for “anonymous structure or union” and note that a (different) part of that extension has since been standardized.
It's a one of a few rough edges in Go.
That’s actually crazy. Why is this even a feature?
Because type Foo struct { sync.Mutex whatever string } var foo Foo foo.Lock() foo.whatever = 42 foo.Unlock() is convenient.
That’s actually crazy. Why is this even a feature?
See how it's used in the standard library io types, it makes for quite nice composition: https://go.googlesource.com/go/+/refs/heads/master/src/io/io...
(It also feels to me that this sort of anonymous embedding is materially different for interfaces vs structs, though I admit that from a type-theoretic perspective it’s not.)
That’s actually crazy. Why is this even a feature?
IMHO it should be a compiler error. This is just so loose... a wheel fell off.
That’s actually crazy. Why is this even a feature?
Because type Foo struct { sync.Mutex whatever string } var foo Foo foo.Lock() foo.whatever = 42 foo.Unlock() is convenient.
foo.mu.Lock()
This way you don't expose your primitives, preventing poor usage from causing a deadlock. Generally you don't want the user of your struct to have to know when or when to not lock.
That’s actually crazy. Why is this even a feature?
https://go.dev/play/p/r04tPta1xZo
So the whole article is basically about using the language in a way you normally would ever do.