I have not read your blog. But in my opinion, what Apple called protocol
programming is actually so called functional programming. It is not object
programming at all. It uses protocols and structs to avoid object
programming.I don't think most functional programmers would recognize
protocol-oriented programming as what they do. It is true that one of
the main benefits we see in protocol-oriented programming is that it
allows one to use *mutable* value types, instead of classes, in
polymorphic contexts. Functional programming is largely concerned with
immutable data, where the distinction between value and reference
semantics disappears, and it doesn't matter if you're using classes or
not. But the main thing in FP is the use of higher-order functions,
which Swift enthusiastically supports, but have nothing whatever to do
with protocol-oriented programming.Your e-mail touches on one of the things that excites me the most
about Swift. As you say “But the main thing in FP is the use of
higher-order functions, which Swift enthusiastically supports, but
have nothing whatever to do with protocol-oriented programming”.
Swift isn’t just a Protocol-Oriented programming language or an
Object-Oriented language or a functional programming language it is
actually all of them and more. While other languages attempt to
support different paradigms, in my opinion, Swift is one of the few
language that actually does a good job at supporting multiple
paradigms.In the conclusion section of my post, I mention that while I pointed
out a lot of ways that I believe POP is superior to OOP I would not
say that POP is a clear winner over OOP.It would be interesting to see where you think OOP has a distinct
advantage due to fundamental properties of the paradigms (rather
than artifacts of an immature implementation of protocol language
features)I would not say that OOP has a distinct advantage over POP based on
the fundamental properties of the paradigms. However, if I were
pressed I would say that OOP does have an advantage over POP in the
area of data structures because of POP emphasis on value types over
reference types.
“Protocol-oriented” doesn't mean “no reference types.” It means you're
not forced into reference semantics just because you want polymorphism.
For example we cannot create a linked list with a value type.
Not true, in fact.
enum List<T> {
case Empty
indirect case NonEmpty(T, List)
}
var x: List = .NonEmpty(3, .NonEmpty(4, .Empty))
There are other ways, but that's the simplest in Swift.
If we tried we would get a compile time error that says: “Recursive
value type ‘Type’ is not allowed.There are two arguments that I could make off the top of my head
against my last statement. The first argument would be: Is preferring
value types to reference types actually part of OOP.
I presume you meant POP. Being forced to use reference types is part of
OOP.
I will address this in my next e-mail where you ask me what I mean by
my statement that POP is about so much more than the protocol. The
second argument would be that we are not limited to value types with
POP and we are able to still use reference types.
Exactly.
While it is true that we are still able to use value types
with POP
reference types?
however if we take Apple’s recommendation and use value types
for our custom types we really should try our best to avoid reference
types. It could get confusing if some of our types are reference
types and some are value types especially for larger enterprise type
projects.
No, some things are fundamentally references, as I noted in the talk:
https://github.com/ASCIIwwdc/wwdc-session-transcripts/blob/master/2015/408.vtt#L3082
Luckily in XCode with have the quick documentation where we can hold
down the option key and click on the type in question to tell us if it
is a value or reference type however we do not have that option
outside of the Apple’s ecosystem like when we are developing Linux
applications with Swift. Therefore we need to be careful on how and
when to use reference and value types.
You always do need to be careful about that, regardless, because they
have different semantics.
Where I really think OOP has a very distinct advantage of POP is that
it has been around for so long, has been vetted in more projects then
either of us can count and it is very well documented.
Yes, that was the one argument I thought could be defensibly made for
OOP over POP.
I don’t know if anyone can really say that Apple has documented what
POP is and isn’t very well
Absolutely, we have not.
which is the reason I wrote my book on POP and why I plan on writing
additional posts on it as well.
I'm looking forward to seeing more of that, and I like to help you
capture more of what we mean by POP.
If you do a search on the Internet for Protocol-Oriented programming
you get a number of different views on what it is and what it isn’t.
Most of the articles, in my opinion, take a very narrow view of POP
and try to fit it into the OOP model but with an Interface first
approach which, once again in my opinion, misses the larger view.
Yes!
···
on Sun Mar 06 2016, Jon Hoffman <hoffman.jon-AT-gmail.com> wrote:
On Mar 6, 2016, at 1:12 AM, Dave Abrahams via swift-users <swift-users@swift.org> wrote:
on Sat Mar 05 2016, Jon Hoffman <swift-users-AT-swift.org> wrote:On Feb 25, 2016, at 7:35 PM, Dave Abrahams via swift-users <swift-users@swift.org> wrote:
on Sun Feb 14 2016, zhaoxin肇鑫 <swift-users-AT-swift.org> wrote:
Once again I will explain this more in my next e-mail where I address
your question about what I mean when I say that POP is about so much
more than the protocol.Jon
The winner is actually the programmer because we are not limited to
one programming paradigm. We can choose the paradigm that fits our
needs. Personally I have use POP in a number of projects and I
definitely prefer it to OOP or FP but I would not criticize anyone
that uses the other two because they are very valid paradigms that
have proven over time.--
-Dave_______________________________________________
swift-users mailing list
swift-users@swift.org
https://lists.swift.org/mailman/listinfo/swift-users
--
-Dave