Well, from what I understand, Go has a separation between "interface" and "implementation", correct? You use this blob of code to specify the interface and this blob to implement the implementation of the interface.
In most of my examples, I showed how you can use traits like interfaces/protocols: the trait specifies traits and functions implement the behavior. But you can also use "provide" to implement the behavior directly in the trait. So my traits system blends the two together.
And you can use them as wrappers and data structs, something that I don't think you can do with interfaces in Go.
---
In addition, from what I understand, Go basically says, "if ANY type implements these functions with these signatures, it's a member of this interface."
My traits are more restrictive than that: the data type has to be tagged with a trait in order to be recognized as possessing that trait.
In other words, Go's system is a lot like Python's system: if it has these methods, it's a member of the type. Except Go also uses the function's argument and return signatures to further disambiguate, so Go avoids a lot of the problems of Python's system.
Go basically says, "if ANY type implements these functions with these signatures, it's a member of this interface."
Yes, this is I think the most innovative aspect of Go interfaces, and one of Go's best features. It's duck typing in a statically type-checked language. It avoids Java's problem of tagging classes with long lists of interfaces that they implement.
Well, from what I understand, Go has a separation between "interface" and "implementation", correct?
Given the above property there isn't really an implementation anymore. Individual types just have to implement the right functions, but that isn't really a blob of code to implement any single interface.
