[swift-users] Comparing POP to OOP

Tue Mar 8 12:27:49 CST 2016

> On Mar 7, 2016, at 6:48 PM, Jon Hoffman via swift-users <swift-users at swift.org> wrote:
> 
> 
>> On Mar 7, 2016, at 6:34 PM, Dave Abrahams <dabrahams at apple.com <mailto:dabrahams at apple.com>> wrote:
>> 
>> 
>> on Mon Mar 07 2016, Jon Hoffman <hoffman.jon-AT-gmail.com <http://hoffman.jon-at-gmail.com/>> wrote:
>> 
>>>> 
>>> 
>>> 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.
> 
> While global functions do not let us provide default implementations for protocols themselves, we are able to create a global function that can perform common functionality on any instance of a type that conforms to a protocol thereby avoiding duplicating implementations in our types that conform to a protocol.   Personally I am not a fan of that approach and do not believe it is a good protocol oriented approach.
> 
> 
>> 
>>> 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.
> 
> Now it is your turn to tell me that I am taking a too narrow of a view on Protocol-Oriented programming :)  After all I have said that about others, it is only fair for you to say the same thing to me when I do.  You are correct I have been thinking of it only with Swift and should look at it separately from the language.   
> 
> From the time I first saw your presentation I have only looked at it from a Swift point of view so it may be hard to separate them in my mind however I think it could be quite fascinating to think about it outside of language now that you mention it.   
> 
> 
>> 
>>>>> 
>>> 
>>> 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
>>> 
>>>> 
>>> 
>>> 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 ;-)
> 
> Just need to decide how to approach it because if a blog post is too long, people tend to not read it all and as you can see, I do tend to write a lot ;) even when it is not necessary. 
> 
> 
>> 
>> 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.
> 
> Unless I am misunderstanding what you are saying here, Java interfaces do support generic programming:  https://docs.oracle.com/javase/tutorial/extra/generics/simple.html <https://docs.oracle.com/javase/tutorial/extra/generics/simple.html>  
> 
> 

I think “static” is the operative word there.

>> 
>>>>> 
>>> 
>>> 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.
>>> 
>>>> 
>>> 
>> 
>> 
>> Footnotes: 
>> [¹]  https://github.com/apple/swift/blob/master/test/Prototypes/GenericDispatch.swift <https://github.com/apple/swift/blob/master/test/Prototypes/GenericDispatch.swift>
>> 
>> -- 
>> -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/20160308/921657e6/attachment.html>