[swift-users] Comparing POP to OOP

Sun Mar 6 18:40:05 CST 2016

I am going to try to answer all of your questions at once (sorry if I miss anything), which is why I am top posting here.  Also sorry for the long e-mails but I am trying to capture what I want to say and still keep the response as small as possible but I am not doing a good job at the small part.

As an architect and developer, I look at POP as more than just developing to an interface.  If we were to take the view that POP was simply about an interface first design then we would be able to say that Java and C# could be POP languages.  While there are plenty of approaches like OSGI that take an interface first approach, they still use the fundamentals of OOP in their design (reference types, class hierarchies).

You say that you do not view extensions themselves as a fundamental part of POP.  My response to that is:  Can we really have POP without protocol extensions?  Without protocol extensions, if we had common functionality between our conforming types we would need to take one of the following three approaches: 

    *  We would need to create large monolithic super classes as we do with OOP that all conforming types would also inherit from.

    *  Have large amounts of duplicate code in our types

    *  Use global functions

While these approaches have worked in the past, in my opinion (and I know some will argue this) they are not ideal solutions.  With protocol extensions we are able to have our cake and eat it too (and who does not like cake).  We are able to define smaller, very specific protocols (rather than monolithic super classes) and also provide an implementation for functionality that is common to our conforming types thereby avoiding duplicate code and global functions.  Therefore would POP really be a viable programming paradigm without protocol extensions?

If you take that logic further, then what is actually part of the POP paradigm?  Apple really hasn’t defined that and has seemed to have left that question up to the community.  Looking at that question from an architect’s point of view then I can see a number of area that we can include.  In my book I included sections on the type choices that we have (classes, structures, enumerations, tuples…), error handling, protocols and extensions.  From one of your earlier e-mails, hindsight being 20-20, maybe I should have had a separate section on generics.  I did touch on generics in the protocol chapter but maybe I do need to expand on that.

Where I see ECS design to be similar to POP (in my opinion) is in ECS every entity consists of one or more components which add additional behavior or functionality to the entity.  With POP we can think of the components as the protocol (with protocol extensions).   Then each protocol that a type conforms to will add additional behavior or functionality similar to ECS.  With OOP and single inheritance as we have with Swift, we have the monolithic super classes rather than smaller components like POP and ECS.  This is one of the things that has drawn me to POP.

I kept the e-mail as small as I could and hopefully I still got my ideas across.

Jon

> On Mar 6, 2016, at 1:30 AM, Dave Abrahams via swift-users <swift-users at swift.org> wrote:
> 
> 
> 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
> 
> _______________________________________________
> swift-users mailing list
> swift-users at swift.org
> https://lists.swift.org/mailman/listinfo/swift-users

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.swift.org/pipermail/swift-users/attachments/20160306/e74285d9/attachment.html>