[dunham]

A "protocol" in swift is equivalent to an "interface" in Java.

"protocol" seems to be the older name (per one of the guys that wrote Java):

> I'm pretty sure that Java's'interface' is a direct rip-off of Obj-C's 'protocol'

   -- https://cs.gmu.edu/~sean/stuff/java-objc.html

So "protocol oriented programming" is just advocating the use of swift's equivalent of java interfaces. (It'd be "interface oriented programming" in Java.)

Edit: apologies if you know all this already, it just sounded like you were asking "what makes this protocol stuff better than interfaces".

[TeMPOraL]

> "protocol" seems to be the older name (per one of the guys that wrote Java)

Quite likelym as another Guy (Steele) responsible for Java was also a big name in the Lisp world, including chairing the committee that wrote ANSI standard for Common Lisp. In the Lisp world, protocols were a known concept. In CL nomenclature, a protocol is a set of generic functions and types used by those functions. Which is kind of like a Java interfaces, except with multiple dispach based on any of the arguments instead of the typical single dispatch of Java and friends.

For example from TFA, a CL protocol would be a #'draw generic function and a 'drawable and 'renderer abstract types. The particular #'draw methods could be specialized on either argument (or both), and we could also imagine another protocol consisting of (the same) renderer type and some geometry-related generic functions.

Point being, protocols are both an old and very useful concept, and like usual, C++/Java-like languages only allow expressing a small subset of it.

[saurik]

The term from Objective-C came directly from Smalltalk, which had almost directly the same concept. Really, Objective-C is essentially "what if the bodies of Smalltalk message implementations were coded in a low-level language?".

I am fascinated, though, by your claim that Lisp also used this term... before reading it I would have been 100% sure that it didn't. I just spent ten minutes trying to find documentation of this, and can't find it... but I am not a native speaker of Lisp and so don't always know where to look; can you point me at a reference? (FWIW, I know of the meta-object protocol, which afaik is a singular thing at a different level of abstraction, and I know about classes and methods and generic functions and mulmethods, which seem like what you are talking about but aren't described by protocol?)

[TeMPOraL]

Common Lisp doesn't use this term at the language level - nor does any other Lisp I know, except Clojure. But it shows up around the language. Like, the Metaobject Protocol. Or CLIM - the Common Lisp Interface Manager - has a whole large spec defined mostly in terms of protocols[0].

Where do protocols originate from, I don't know. Maybe Smalltalk. But I first met them in Common Lisp ecosystem.

--

[0] - http://bauhh.dyndns.org:8000/clim-spec/2-5.html#_23

[lispm]

Protocols were used in the original CLIM implementation:

https://github.com/franzinc/clim2/blob/master/utils/protocol...

https://github.com/franzinc/clim2/blob/master/clim/stream-de...

[TeMPOraL]

Oh yes, I know. I was part of the effort of getting that codebase running on modern CL implementations.

https://github.com/dkochmanski/clim-tos/graphs/contributors

Two lessons I learned:

One, Common Lisp code is surprisingly stable over time, with 90% of it still working on CCL/SBCL even though the codebase predates the language standard and is older than I am (don't be mislead by that 1991 on Github, it's much older).

Two, oh my god, trying to understand a large codebase seriously abusing :before/:after/:around methods in large class graphs is not an easy task, though arguably it's more of an issue with available tooling. With better ways to explore runtime program state, it would be much easier to understand and improve such code. I may have written about this last night here: https://mastodon.technology/@temporal/100646861775747986.

Also fun fact, this project is the only case where macroexpanding code crashed my SBCL...

Anyway, let that codebase be and serve as a historical reminder; for more modern implementation of CLIM standard, I'll direct everyone to https://common-lisp.net/project/mcclim/.

[jfoutz]

The only place i can think of is Norvig's slides on design patterns - http://norvig.com/design-patterns/

[Someone]

Equivalent, but not exactly the same, mostly in the sense that Java is less dynamic than Swift. Ones I know of:

- In Java, you have to declare the interfaces that a class implements when you declare the class. In Swift, you can add conformance of a class to a protocol, even if you don’t have access to the class’s source code.

- In Swift, protocol definitions can contain implementations of methods (I think this is being or has already been added to Java recently). For example, a method foo that takes a string argument could call the foo overload taking a character for each character in the string. That way, classes conforming to the protocol need not define the method taking a string.

- Even if the protocol definition doesn’t declare that default implementation, you can add one by writing an extension method.

All of those are useful, but also can make it hard to understand what code exactly is being called.

(More info at https://docs.swift.org/swift-book/LanguageGuide/Protocols.ht...)

[saagarjha]

> In Swift, protocol definitions can contain implementations of methods

Technically, no, they can't. What you do is write your protocol as usual, then extend the protocol with a default implementation.