Structural subtyping is a terrible approach. It means Go Interfaces can only abstract over a type's structure, but not its laws/semantics/algebra.
For example, not every type with a combine function is a monoid (combine must be associative). In Go, every type with combine is automatically a monoid.
It only conforms to the interface if it has the correct parameters as well. The examples listed don’t include type information, which was my oversight when trying to make it simple.
Also, interfaces in Go describe what a structure does rather than what it is, and they should be used as such. So something with a combine method is usually a Combiner rather than something with a fancier name.
Also, interfaces in Go describe what a structure does rather than what it is, and they should be used as such.
Yes, that was precisely my point. They let you abstract over the signature of a function, but not over its laws. Therefore, Go's expressiveness is limited.
For further actions, you may consider blocking this person and/or reporting abuse
We're a place where coders share, stay up-to-date and grow their careers.
Structural subtyping is a terrible approach. It means Go Interfaces can only abstract over a type's structure, but not its laws/semantics/algebra.
For example, not every type with a
combinefunction is a monoid (combinemust be associative). In Go, every type withcombineis automatically a monoid.It only conforms to the interface if it has the correct parameters as well. The examples listed don’t include type information, which was my oversight when trying to make it simple.
Also, interfaces in Go describe what a structure does rather than what it is, and they should be used as such. So something with a
combinemethod is usually aCombinerrather than something with a fancier name.Yes, that was precisely my point. They let you abstract over the signature of a function, but not over its laws. Therefore, Go's expressiveness is limited.