6 ms·
> That's something that is not often not acknowledged: Go's sort is implemented as a function that operates on an interface. This is not the style of object-ori
by moomin 3y ago
> That's something that is not often not acknowledged: Go's sort is implemented as a function that operates on an interface. This is not the style of object-oriented programming most people were familiar with, but it's a very powerful idea.
I feel like most of this is just ignoring the prior art. C#'s sort works the same way. Admittedly, this isn't obvious because of the way it's implemented. But if you're a language designer you don't have much of an excuse there.
- PH95VuimJjqBqy 3y agoit would behoove you to quote the entire context > Robert and I came up with the same idea pretty much simultaneously: using methods on types to provide the operations that sort needed. That notion quickly grew into the idea that value types had behaviors, defined as methods, and that sets of methods could provide interfaces that functions could operate on. Go's interfaces arose pretty much right away. > That's something that is not often not acknowledged: Go's sort is implemented as a function that operates on an interface. This is not the style of object-oriented programming most people were familiar with, but it's a very powerful idea. What he actually said is that being able to pass a value type into a sort function and have it work without needing to explicitly define and implement an interface was not a style that most people are familiar with. and indeed, C# absolutely does NOT work that way. It probably would have been better for you to claim that Ruby had prior art, but even that's implemented in an entirely different way it's just that the behavior is closer to Go's behavior than C# is.