[swift-users] Comparing POP to OOP

[Dave Abrahams]

on Sun Mar 06 2016, Jon Hoffman <hoffman.jon-AT-gmail.com> wrote:

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

Forty lashes with a wet noodle for you, my friend.

> Also sorry for the long e-mails 

Okay, fifty :-)

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

Maybe you ran out of time.
http://quoteinvestigator.com/2012/04/28/shorter-letter/

> 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

My point about protocol extensions has to do with the “extension” part
rather than the “protocol” part.  The fundamental property of extensions
is that you can add to a type's interface *without owning that type*.
There are other ways one could express the same kind of code sharing for
protocols without having a mechanism that allows arbitrary extension by
authors that don't own the protocol.  For example, the same basic
expressive capabilities were built into
http://www.generic-programming.org/software/ConceptGCC/, which in many
ways was a precursor to Swift's generics system in the form of concept
maps.  Extensions happened to be the most convenient vehicle for
bringing these capabilities into Swift.

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

Yes, but you'd need other mechanisms to achieve the same ends.

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

Mea culpa.  But we only have so much time for writing blog posts,
etc. while simultaneously changing the face of all Apple APIs and trying
to develop the Swift standard library ;-)

I'm just glad there are thoughtful and insightful authors like you out
there to pick up the thread.

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

Great idea.

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

If what you're saying is that POP is better than OOP for decomposing
designs in Swift, I won't argue.  ECS is a different path to a granular
design, but AFAICT that's where any similarity to POP ends.

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

-- 
-Dave