[jnbiche]

While most statically-typed functional programming offer some approach to composition similar to Swift prototols, the concept goes above and beyond the idea described in the article you posted, which relates more to the idea of programming with immutable data.

So similar compositional techniques to Swift protocols would be typeclasses in Haskell, traits in Scala, module interfaces in ML languages (which have to be used at the module-level via functors instead of at the value-level like the other examples), etc.

Edit: I should have read to the end. I stopped after reading a few paragraphs of what looked like a basic interface vs inheritance discussion. Turns out, at the mid-point, he introduces an "alternative" to that approach, which is indeed more or less functional programming. As much as I like functional programming, (his "Value-Oriented-Programming"), interfaces are often quite useful when programming in the large.

[kragen]

The article doesn't seem to be promoting using the Swift protocol approach to composition — at least, that's not what it uses the "Value-Oriented Programming" name to refer to. Instead, it's saying that instead of using the Swift protocol approach to composition, you should return a complicated value of some concrete data type from your function.

[jnbiche]

Oh, my apologies. I read a few paragraphs and it looked like a basic tutorial about Swift protocols and inheritance vs composite, so I stopped. I'll read the whole thing.

Edit: Yeah, you're right. I read to the end and that's pretty much functional programming as you suggested. I'm not convinced it's always better than using interfaces. Like most things, I think it depends. For example, particularly when programming "in-the-large", I think being able to package up different contexts (like a TestRenderer) into different protocol implementations is often an advantage of that approach, not a weakness, as he seems to imply.

[kragen]

Yeah, I'm not sure he's right that one technique is clearly better than the other. They're only separated by a transformation to explicit CPS and a doesNotUnderstand: override, but that isn't in itself an argument that the distinction is unimportant.