[swift-users] Comparing POP to OOP

[Dave Abrahams]

on Sat Mar 05 2016, Jon Hoffman <swift-users-AT-swift.org> wrote:

>> On Feb 25, 2016, at 7:38 PM, Dave Abrahams via swift-users <swift-users at swift.org> wrote:
>> 
>> 
>> on Mon Feb 15 2016, Jon Hoffman <swift-users-AT-swift.org> wrote:
>> 
>
>>> Thank you for the feedback however you cannot design the code as you
>>> describe, if I understand your explanation correctly, because one of the
>>> requirements is the animals may be apart of multiple categories.  As the
>>> example in the post shows the alligator belongs to both the Land and the
>>> Sea categories.  In you description that would mean that the Alligator type
>>> would need to be a subclass of both the Land and Sea superclasses which is
>>> not permitted.  Remember that one of the drawbacks with OOP is a subclass
>>> can only inherit from one superclass.
>> 
>> That's true in Swift, but not in all realizations of OOP.  If your
>> article is merely using protocols to get the benefits of multiple
>> inheritance from abstract classes, it may not touch at all on what
>> differentiates OOP from POP at a fundamental level.
>
> You are absolutely correct; with protocols we do gain a lot more than
> just multiple inheritance.  In this post I touch on protocol
> composition 

In what ways do you see “protocol composition” as being distinct from
“multiple inheritance?”

> and also extensions just to name two of them.  

I don't view extensions themselves as a fundamental part of POP.  After
all, we can extend classes as well as protocols.  It's possible to
express the things that we do with protocol extensions using other
language features that don't make types fully open for extension outside
the scope in which they're defined.

> One of the things that I do emphasize when I talk about
> Protocol-Oriented programming is it is about so much more than just
> the protocol.

Do tell!  What do you mean?

> To be honest, I think that Apple may have done a disservice to POP by
> giving it the name “Protocol-Oriented Programming”.  With OOP and POP
> having such similar names, people tend to relate them together and in
> my opinion, how you design your application with POP is fundamentally
> different than with OOP.  

Isn't that the whole point?  It's a different orientation.

The way in which OOP is “object oriented” is that it starts with the
premise that the fundamental unit of abstraction is the object,
i.e. class instance.  The way in which POP is “protocol oriented” is
that it says the fundamental unit of abstraction is the protocol.

> Hopefully I will be able to write some additional posts about
> designing applications in a POP way using case studies.  Just a matter
> of finding time.
>
> In one of the e-mails about this post, someone mentioned
> Entity-Component Systems
> (https://en.wikipedia.org/wiki/Entity_component_system).  I personally
> have not used ECS however from what I read from the links provided in
> that e-mail, in a lot of ways the design philosophy behind POP seems
> to be closer to ECS than OOP

>From what I read there, an ECS has almost nothing in common with what
I've tried to capture as protocol-oriented programming.  In particular,
ECS seems to much closer to “stringly typed” or dictionary-oriented
programming, with lots of dynamic interrogation for object properties
rather than use of strong static typing.

-- 
-Dave