3 ms·

I disagree. This is the classic case for protocols. Look what he says: "I’m using a protocol for the Account type. There are classes that conform to the Accoun

I disagree. This is the classic case for protocols. Look what he says: "I’m using a protocol for the Account type. There are classes that conform to the Account protocol: TwitterAccount, AppNetAccount, LinkedInAccount, etc." The important bit is the "etc." at the end. The types of accounts he wants to support is open ended. He also mentions a plug-in API. You can't have third parties come in and extend some algebraic data type. If this is not a case for protocols then there is no such case at all and protocols should be removed from the language.

Manishearth 11y ago
> protocols should be removed from the language. That's a bit harsh. You forget that protocols are useful for generics too. But yes, if they want it to be extensible, protocols would be the way to go. Looking deeper into the issue, it seems like this isn't really an issue with protocols, just an issue with the design of Hashable or Equatable (either allow Equatable to work with protocol objects, or move the Equatable dependency of Hashable to a different kind of Equatable). This sounds like a nitpick, but it's the difference between language and API design, and the latter is often easier to evolve. It also means that this can be fixed by a ProtocolHashSet<T> library which does hashing differently without touching the compiler/stdlib at all.
captaincrowbar 11y ago
To me this looks like exactly the sort of situation where classical OO inheritance is the right answer. All of those things are kinds of Account and should have a common base class.
- Manishearth 11y ago
  Classical OO inheritance is the right answer in a language that supports it, though. There may be equally ergonomic ways of doing it in languages with ADTs. (Which may or may not be the case here, depending on extensibility)

3 ms·

I disagree. This is the classic case for protocols. Look what he says: "I’m using a protocol for the Account type. There are classes that conform to the Accoun

by fauigerzigerk 11y ago

Manishearth 11y ago
> protocols should be removed from the language. That's a bit harsh. You forget that protocols are useful for generics too. But yes, if they want it to be extensible, protocols would be the way to go. Looking deeper into the issue, it seems like this isn't really an issue with protocols, just an issue with the design of Hashable or Equatable (either allow Equatable to work with protocol objects, or move the Equatable dependency of Hashable to a different kind of Equatable). This sounds like a nitpick, but it's the difference between language and API design, and the latter is often easier to evolve. It also means that this can be fixed by a ProtocolHashSet<T> library which does hashing differently without touching the compiler/stdlib at all.
captaincrowbar 11y ago
To me this looks like exactly the sort of situation where classical OO inheritance is the right answer. All of those things are kinds of Account and should have a common base class.
- Manishearth 11y ago
  Classical OO inheritance is the right answer in a language that supports it, though. There may be equally ergonomic ways of doing it in languages with ADTs. (Which may or may not be the case here, depending on extensibility)