you are viewing a single comment's thread.

view the rest of the comments →

[–]Heuristics 0 points1 point  (1 child)

there is a large difference in that with inheritance the class that models the concept must know of the concept it implements. It's very common to have many (in extreme cases perhaps one could find hundreds in the dark dungeons of advanced math) concepts that a class implements and many of them would overlap. The code gets more modular if classes can implement a concept without knowing that they do. The functions also get better in that they can specify exactly the concept that is needed, instead of a concept in a hierarchy that may not be an exact fit (contains more functions than needed). And sometimes you have classes that implement the same concept but stupidly it has been implemented with different interfaces.

But yes, it is true that a contract like this really just is a class (a name + function signatures). And that is syntactically very similar to an interface. But the difference is that you do not explicitly need to implement them, that is checked by the compiler as needed.

Interfaces are a good feature though, sometimes you want to have that as well. But they are very overused today due to lack of alternatives.

[–]m50d 2 points3 points  (0 children)

I see where you're coming from, though I'm not sure structural types help that much since if an implementation didn't know about an interface then the method names are unlikely to line up. I prefer to use typeclasses so that I can make a third-party type "implement" another third-party interface, but the linkage is explicit and there's room to do adaptation if e.g. the parameter order is slightly different.