[swift-users] Comparing POP to OOP

[Dave Abrahams]

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

>> On Mar 7, 2016, at 12:16 AM, Dave Abrahams <dabrahams at apple.com> wrote:
>> 
>> 
>> 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.
>
> Not the wet noodle, anything but that.  :)  
>
>> 
>>> 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/ <http://quoteinvestigator.com/2012/04/28/shorter-letter/>
>
> Oh if we only had more time to do all of the things we wanted or at least to shorten our e-mails.
>
>> 
>>> 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.
>
> I agree that there is other ways we can do code sharing besides
> protocol extensions however as you pointed out extensions are the most
> convenient way.  I would also say that in my opinion protocol
> extensions are also the most elegant and one of the easiest for new
> programmers to learn when coming from an OOP background.  Developers
> coming from a functional backgrounds can still use global methods.

Well, global functions (except operators—an evil hack that I expect to
be removed someday [¹]) don't actually allow us to provide default
implementations for protocol requirements, so they're not a substitute
for protocol extensions.

> To help grow POP with Swift, in my opinion, there really should be a
> standard or recommended way for adding common functionality even if
> some developers prefer to take a different approach.  

I'm not talking about alternative approaches that are available in
Swift.  I'm talking about different ways to get the basic generics
capabilities that fall out of protocol extensions, but using language
features we don't have.  I agree that protocol extensions are a
beautifully elegant way to get these capabilities, but you could still
do the same kind of programming with a different mechanism that doesn't
allow for open-ended extension.

> This will allow us to write books and articles about POP and show a
> consistent approach.  If different authors take different approaches,
> it could get confusing for other developers that are trying to figure
> out what POP is.  To me standardizing on protocol extensions make the
> most sense.

Of course; that's the way it's done in Swift.  I'm trying to say that in
principle you can take a protocol-oriented approach in many different
languages and express the same kinds of ideas as we do in Swift, though
it may not be as elegant.  Heck, I was doing much of this in C++ for
years, and C++ doesn't even have protocols!  Of course, it's much uglier
to do so.  Swift is the best language I've seen for expressing the
protocol-oriented approach.  It's also protocol-oriented at its core,
using protocols for literals, looping, and bridging to Objective C.

> I can see the benefits with also showing other approaches at the same
> time we show protocol extensions larger print mediums like books
> however having that standard approach will make it easier all the way
> around.

No, I don't suggest you show other approaches.  I'm just trying to
suggest that you think of what POP means separately from the language
mechanisms used to realize it.

>>> 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 ;-)
>
> With all of the talent at Apple, you should have all that completed
> next week and still have time for a paint ball tournament, right?  :)

Mmm, delicious paint balls. Yum.

>> I'm just glad there are thoughtful and insightful authors like you out
>> there to pick up the thread.
>
> Thank you for the compliment
>
>> 
>>> 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.
>
> Generics are a pretty broad subject to cover all at once, what parts
> do you think matter the most when it comes to POP?

All of them, sorry ;-)

What makes protocols in Swift different from Java interfaces (or
Objective-C protocols for that matter) is that they support static
polymorphism and generic programming.

>>> 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 do not know enough about ECS to comment any further than the
> granular approach but yes I think that approach is similar to what POP
> is.
>
>> 
>>> 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
>


Footnotes: 
[¹]  https://github.com/apple/swift/blob/master/test/Prototypes/GenericDispatch.swift

-- 
-Dave