[swift-users] Comparing POP to OOP
hoffman.jon at gmail.com
Mon Mar 7 20:48:58 CST 2016
> On Mar 7, 2016, at 6:34 PM, Dave Abrahams <dabrahams at apple.com> wrote:
> on Mon Mar 07 2016, Jon Hoffman <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
> 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
>> 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
> [¹] https://github.com/apple/swift/blob/master/test/Prototypes/GenericDispatch.swift
-------------- next part --------------
An HTML attachment was scrubbed...
More information about the swift-users