Hacker News Reader

Comment by Manishearth | Hacker News Reader

I'm not a Swift person, so I might be wrong, but this seems like a case where composition over inheritance is preferred. Protocols in Swift (and traits in Rust) are not supposed to be used to emulate classical inheritance; though they can be. Enums/ADTs/sum types/whatever you call them are what you're supposed to use in such cases.

View on HN

Yeah you're right. If you want to stick with value types and store those values in an Array where the array can only store one type then you have to use an Enum instead of classes. I think there are a few people getting confused by not identifying enums in Swift as a more powerful construct than in C/ObjC.

We basically have that same issue in Rust :)

And with associated values in enum types they behave in a similar way to case classes in Scala that extend a sealed trait.

For example I've been working on a Json library that stores everything in an enum (ADT):

  public enum JsValue {
    case JsString(String)
    case JsNumber(Double)
    case JsObject([String: JsValue])
    case JsArray([JsValue])
    case JsBoolean(Bool)
    case JsNull
  }

Don't trait objects (https://doc.rust-lang.org/stable/reference.html#trait-object...) solve this problem?

Well, yes. But that wasn't what I was talking about.

Trait objects in Rust let you emulate inheritance. The issue I was talking about is that folks from inheritance-heavy languages use this as the de facto design pattern, and then stuff doesn't work so well, because you're not supposed to use inheritance so much (the languages aren't designed with this in mind). The correct option is to use enums and composition over inheritance wherever possible.

In functional languages, functionality should be extrinsic (case match values from the outside), while in OO languages like functionality is intrinsic (polymorphic method members called on the value). However, for things like hashing, intrinsic works way better (hence traits, protocols, type classes, and so on).

Saying use composition over inheritance "wherever possible" can lead to some cargo culting on its own. It is always possible to use composition over inheritance, but it isn't always wise.

> but it isn't always wise.

Pretty much what I meant, when I said "wherever possible" I meant "wherever possible with decent code", sorry about the confusion.

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.

> 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.

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.

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)

He mentions a plug-in API in the second linked post. Enums would be a good solution, but they can't be extended with more cases by a plug-in.

Yeah, that's when you would use trait objects in Rust (and virtual dispatch protocols in Swift?), but you still probably won't use them exactly the same way.

extensions let you do this with enums (as well as protocols):

  enum Car { 
    case Red 
    case Blue 
  }    
  extension Car { 
    func hello() { 
      print("hello") 
    } 
  } 
  let x = Car.Blue
  x.hello()

https://developer.apple.com/library/ios/documentation/Swift/...

edit: although you can't add a new case to the enum.

> although you can't add a new case to the enum.

That's the point. We all know you can add impls or extensions.

Reply on news.ycombinator.com