[swift-users] Comparing POP to OOP

[Jon Hoffman]

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

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

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. 


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



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

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

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