Comparing POP to OOP

Numerous tutorials that I have seen take a very Object-Oriented approach to the protocol-oriented programming (POP) paradigm. By this statement I mean that they tell us that with POP we should begin our design with the protocol rather than with the superclass as we did with OOP however the protocol design tends to mirror the superclass design of OOP. They also tell us that we should use extensions to add common functionality to types that conform to a protocol as we did with superclasses in OOP. While protocols and protocol extensions are arguably two of the most important concepts of POP these tutorials seem to be missing some other very important concepts.

In this post I would like to compare Protocol-Oriented design to Object-Oriented design to highlight some of the conceptual differences. You can view the blog post here: Mastering Swift: POP and OOP

Jon

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.

zhaoxin

···

On Mon, Feb 15, 2016 at 7:59 AM, Jon Hoffman via swift-users < swift-users@swift.org> wrote:

Numerous tutorials that I have seen take a very Object-Oriented approach
to the protocol-oriented programming (POP) paradigm. By this statement I
mean that they tell us that with POP we should begin our design with the
protocol rather than with the superclass as we did with OOP however the
protocol design tends to mirror the superclass design of OOP. They also
tell us that we should use extensions to add common functionality to types
that conform to a protocol as we did with superclasses in OOP. While
protocols and protocol extensions are arguably two of the most important
concepts of POP these tutorials seem to be missing some other very
important concepts.

In this post I would like to compare Protocol-Oriented design to
Object-Oriented design to highlight some of the conceptual differences.
You can view the blog post here:
Mastering Swift: POP and OOP

Jon

_______________________________________________
swift-users mailing list
swift-users@swift.org
https://lists.swift.org/mailman/listinfo/swift-users

While I agree that simply translating classes into protocols misses the
point, it seems as though your post still only deals with the
dynamically-polymorphic half of the protocol world. I don't see any
generics in there at all, for example. If you're really going for a
comprehensive view of POP, you need to get into that stuff too.

···

on Sun Feb 14 2016, Jon Hoffman <swift-users-AT-swift.org> wrote:

Numerous tutorials that I have seen take a very Object-Oriented
approach to the protocol-oriented programming (POP) paradigm. By this
statement I mean that they tell us that with POP we should begin our
design with the protocol rather than with the superclass as we did
with OOP however the protocol design tends to mirror the superclass
design of OOP. They also tell us that we should use extensions to add
common functionality to types that conform to a protocol as we did
with superclasses in OOP. While protocols and protocol extensions are
arguably two of the most important concepts of POP these tutorials
seem to be missing some other very important concepts.

In this post I would like to compare Protocol-Oriented design to
Object-Oriented design to highlight some of the conceptual
differences. You can view the blog post here:
Mastering Swift: POP and OOP
<http://masteringswift.blogspot.com/2016/02/pop-and-oop.html&gt;

--
-Dave

You should try reading my blog post, hopefully it will change your opinion of Protocol-Oriented programming. I would be interested to hear what you or anyone else think of Protocol-Oriented programming after reading my post.

Jon

···

On Feb 14, 2016, at 8:34 PM, zhaoxin肇鑫 <owenzx@gmail.com> wrote:

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.

zhaoxin

On Mon, Feb 15, 2016 at 7:59 AM, Jon Hoffman via swift-users <swift-users@swift.org <mailto:swift-users@swift.org>> wrote:
Numerous tutorials that I have seen take a very Object-Oriented approach to the protocol-oriented programming (POP) paradigm. By this statement I mean that they tell us that with POP we should begin our design with the protocol rather than with the superclass as we did with OOP however the protocol design tends to mirror the superclass design of OOP. They also tell us that we should use extensions to add common functionality to types that conform to a protocol as we did with superclasses in OOP. While protocols and protocol extensions are arguably two of the most important concepts of POP these tutorials seem to be missing some other very important concepts.

In this post I would like to compare Protocol-Oriented design to Object-Oriented design to highlight some of the conceptual differences. You can view the blog post here: Mastering Swift: POP and OOP

Jon

_______________________________________________
swift-users mailing list
swift-users@swift.org <mailto:swift-users@swift.org>
https://lists.swift.org/mailman/listinfo/swift-users

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.

···

on Sun Feb 14 2016, zhaoxin肇鑫 <swift-users-AT-swift.org> wrote:

zhaoxin

On Mon, Feb 15, 2016 at 7:59 AM, Jon Hoffman via swift-users < > swift-users@swift.org> wrote:

Numerous tutorials that I have seen take a very Object-Oriented approach
to the protocol-oriented programming (POP) paradigm. By this statement I
mean that they tell us that with POP we should begin our design with the
protocol rather than with the superclass as we did with OOP however the
protocol design tends to mirror the superclass design of OOP. They also
tell us that we should use extensions to add common functionality to types
that conform to a protocol as we did with superclasses in OOP. While
protocols and protocol extensions are arguably two of the most important
concepts of POP these tutorials seem to be missing some other very
important concepts.

In this post I would like to compare Protocol-Oriented design to
Object-Oriented design to highlight some of the conceptual differences.
You can view the blog post here:
Mastering Swift: POP and OOP

Jon

_______________________________________________
swift-users mailing list
swift-users@swift.org
https://lists.swift.org/mailman/listinfo/swift-users

_______________________________________________
swift-users mailing list
swift-users@swift.org
https://lists.swift.org/mailman/listinfo/swift-users

--
-Dave

Numerous tutorials that I have seen take a very Object-Oriented
approach to the protocol-oriented programming (POP) paradigm. By this
statement I mean that they tell us that with POP we should begin our
design with the protocol rather than with the superclass as we did
with OOP however the protocol design tends to mirror the superclass
design of OOP. They also tell us that we should use extensions to add
common functionality to types that conform to a protocol as we did
with superclasses in OOP. While protocols and protocol extensions are
arguably two of the most important concepts of POP these tutorials
seem to be missing some other very important concepts.

In this post I would like to compare Protocol-Oriented design to
Object-Oriented design to highlight some of the conceptual
differences. You can view the blog post here:
Mastering Swift: POP and OOP
<http://masteringswift.blogspot.com/2016/02/pop-and-oop.html&gt;

While I agree that simply translating classes into protocols misses the
point, it seems as though your post still only deals with the
dynamically-polymorphic half of the protocol world. I don't see any
generics in there at all, for example. If you're really going for a
comprehensive view of POP, you need to get into that stuff too.

--
-Dave

You are correct that POP is about so much more than what was covered in this introductory post. This post was written to be an introduction to be Protocol-Oriented programming with a comparison to Object-Oriented programming.

POP was introduced to the World less than a year ago. Over the next few years, as Swift changes and matures; the Protocol-Oriented programming paradigm will mature with it. Hopefully I can continue to write about these changes as well.

My book does cover POP and the technologies that make up POP more extensively than this post does however I plan on writing several more posts, as time allows with my day job, to expand not only on this post but also on the material in my book.

Jon

···

On Feb 25, 2016, at 7:29 PM, Dave Abrahams via swift-users <swift-users@swift.org> wrote:
on Sun Feb 14 2016, Jon Hoffman <swift-users-AT-swift.org> wrote:

_______________________________________________
swift-users mailing list
swift-users@swift.org
https://lists.swift.org/mailman/listinfo/swift-users

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

Jon

···

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:

zhaoxin

On Mon, Feb 15, 2016 at 7:59 AM, Jon Hoffman via swift-users < >> swift-users@swift.org> wrote:

Numerous tutorials that I have seen take a very Object-Oriented approach
to the protocol-oriented programming (POP) paradigm. By this statement I
mean that they tell us that with POP we should begin our design with the
protocol rather than with the superclass as we did with OOP however the
protocol design tends to mirror the superclass design of OOP. They also
tell us that we should use extensions to add common functionality to types
that conform to a protocol as we did with superclasses in OOP. While
protocols and protocol extensions are arguably two of the most important
concepts of POP these tutorials seem to be missing some other very
important concepts.

In this post I would like to compare Protocol-Oriented design to
Object-Oriented design to highlight some of the conceptual differences.
You can view the blog post here:
Mastering Swift: POP and OOP

Jon

_______________________________________________
swift-users mailing list
swift-users@swift.org
https://lists.swift.org/mailman/listinfo/swift-users

_______________________________________________
swift-users mailing list
swift-users@swift.org
https://lists.swift.org/mailman/listinfo/swift-users

--
-Dave

_______________________________________________
swift-users mailing list
swift-users@swift.org
https://lists.swift.org/mailman/listinfo/swift-users

Numerous tutorials that I have seen take a very Object-Oriented
approach to the protocol-oriented programming (POP) paradigm. By this
statement I mean that they tell us that with POP we should begin our
design with the protocol rather than with the superclass as we did
with OOP however the protocol design tends to mirror the superclass
design of OOP. They also tell us that we should use extensions to add
common functionality to types that conform to a protocol as we did
with superclasses in OOP. While protocols and protocol extensions are
arguably two of the most important concepts of POP these tutorials
seem to be missing some other very important concepts.

In this post I would like to compare Protocol-Oriented design to
Object-Oriented design to highlight some of the conceptual
differences. You can view the blog post here:
Mastering Swift: POP and OOP
<http://masteringswift.blogspot.com/2016/02/pop-and-oop.html&gt;

While I agree that simply translating classes into protocols misses the
point, it seems as though your post still only deals with the
dynamically-polymorphic half of the protocol world. I don't see any
generics in there at all, for example. If you're really going for a
comprehensive view of POP, you need to get into that stuff too.

--
-Dave

You are correct that POP is about so much more than what was covered
in this introductory post. This post was written to be an
introduction to be Protocol-Oriented programming with a comparison to
Object-Oriented programming.

POP was introduced to the World less than a year ago.

Yes, I was there ;-)

Over the next few years, as Swift changes and matures; the
Protocol-Oriented programming paradigm will mature with it. Hopefully
I can continue to write about these changes as well.

I hope so.

My book does cover POP and the technologies that make up POP more
extensively than this post does however I plan on writing several more
posts, as time allows with my day job, to expand not only on this post
but also on the material in my book.

I'm definitely interested to see more.

Thanks for your work on this,

···

on Sat Mar 05 2016, Jon Hoffman <swift-users-AT-swift.org> wrote:

On Feb 25, 2016, at 7:29 PM, Dave Abrahams via swift-users <swift-users@swift.org> wrote:
on Sun Feb 14 2016, Jon Hoffman <swift-users-AT-swift.org> wrote:

--
-Dave

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)

···

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:

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

Numerous tutorials that I have seen take a very Object-Oriented
approach to the protocol-oriented programming (POP) paradigm. By this
statement I mean that they tell us that with POP we should begin our
design with the protocol rather than with the superclass as we did
with OOP however the protocol design tends to mirror the superclass
design of OOP. They also tell us that we should use extensions to add
common functionality to types that conform to a protocol as we did
with superclasses in OOP. While protocols and protocol extensions are
arguably two of the most important concepts of POP these tutorials
seem to be missing some other very important concepts.

In this post I would like to compare Protocol-Oriented design to
Object-Oriented design to highlight some of the conceptual
differences. You can view the blog post here:
Mastering Swift: POP and OOP
<http://masteringswift.blogspot.com/2016/02/pop-and-oop.html&gt;

While I agree that simply translating classes into protocols misses the
point, it seems as though your post still only deals with the
dynamically-polymorphic half of the protocol world. I don't see any
generics in there at all, for example. If you're really going for a
comprehensive view of POP, you need to get into that stuff too.

--
-Dave

You are correct that POP is about so much more than what was covered
in this introductory post. This post was written to be an
introduction to be Protocol-Oriented programming with a comparison to
Object-Oriented programming.

POP was introduced to the World less than a year ago.

Yes, I was there ;-)

Luckily you, I haven’t been to a WWDC however living on a lake I am able to sit by the lake and watch the video at my leisure. Not really sure which one is better :)

Over the next few years, as Swift changes and matures; the
Protocol-Oriented programming paradigm will mature with it. Hopefully
I can continue to write about these changes as well.

I hope so.

My book does cover POP and the technologies that make up POP more
extensively than this post does however I plan on writing several more
posts, as time allows with my day job, to expand not only on this post
but also on the material in my book.

I'm definitely interested to see more.

Thanks for your work on this,

Thanks, I am definitely getting a number of idea about future posts based on our conversation.

···

On Mar 6, 2016, at 1:08 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:29 PM, Dave Abrahams via swift-users <swift-users@swift.org> wrote:
on Sun Feb 14 2016, Jon Hoffman <swift-users-AT-swift.org> wrote:

--
-Dave

_______________________________________________
swift-users mailing list
swift-users@swift.org
https://lists.swift.org/mailman/listinfo/swift-users

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. For example we cannot create a linked list with a value type. 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 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.

While it is true that we are still able to use value types with POP 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. 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.

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. I don’t know if anyone can really say that Apple has documented what POP is and isn’t very well which is the reason I wrote my book on POP and why I plan on writing additional posts on it as well.

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

···

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:

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

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

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.

I stand corrected; I neglected to think about using the enumeration. Yet another blog post coming from our conversation.

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?

Yes sometimes the fingers don’t always type what the brain tells them too. :)

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.

You are correct however my point with this is with other languages like Java and C# our custom types are reference types. As developers we know this and develop our applications to take this into account. With Swift it is not always clear what type was used to create a custom type especially when we are working outside of Xcode.

Lets say for example that I created a framework that has several custom types and this framework can be used with Swift on the Linux platform. If I do not document my framework well enough it could be hard for other developers to know if I implemented the types as reference or value types without looking at my code. Therefore with Swift we need to take extra caution on how we use reference types because developers could assume they are value types when they are not.

Now if Apple could port Xcode to the Linux platform... :). Just one more thing to do in all of your spare time, right? :)

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.

This has allowed for us to experiment a little and figure out what we think it should be. Maybe we will come up with some good ideas that you did not think of, or maybe we will go down the wrong path that you will need to correct . Kind of like our conversation right now.

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.

I can definitely say that our conversation has helped me understand more about what Apple understands POP to be and I welcome any help/advice/feedback that you can provide. Consistency is important to help people adopt POP.

Jon

···

On Mar 6, 2016, at 11:53 PM, Dave Abrahams <dabrahams@apple.com> wrote:
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:

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!

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

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.

I stand corrected; I neglected to think about using the enumeration.

Note again: there are other ways, e.g. you can make it immutable or
build it with COW.

Yet another blog post coming from our conversation.

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?

Yes sometimes the fingers don’t always type what the brain tells them too. :)

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.

You are correct however my point with this is with other languages
like Java and C# our custom types are reference types.

I don't think so:

C#: Value vs Reference Types in C#
Coming in Java 9: Devoxx officially kicks off with Spring, Java EE 8, lambdas and value types | TheServerSide

···

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

On Mar 6, 2016, at 11:53 PM, Dave Abrahams <dabrahams@apple.com> wrote:
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:

--
-Dave

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

I stand corrected; I neglected to think about using the enumeration.

Note again: there are other ways, e.g. you can make it immutable or
build it with COW.

So for the last two hours or so I put myself on a task to create a mutable linked list using value types and to do it in an elegant way (Hey I love challenges and beating my head against the wall). While I have found one working solution so far it is pretty ugly therefore I have to ask myself, that even though it is preferred that we use value types overall, should it be preferred that we use reference types for mutable data structures like this? Trust me, I have not giving up finding an elegant solution yet just wondering your thoughts on that.

Yet another blog post coming from our conversation.

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?

Yes sometimes the fingers don’t always type what the brain tells them too. :)

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.

You are correct however my point with this is with other languages
like Java and C# our custom types are reference types.

I don't think so:

C#: http://www.albahari.com/valuevsreftypes.aspx
Coming in Java 9: http://www.theserverside.com/news/2240234686/Devoxx-officially-kicks-off-with-Spring-Java-EE-8-and-the-women-of-IT

About a year ago, at my day job we had to build an app for a Windows 8 tablet and I took on the challenge myself (love learning new things) and after using C# quite a bit over the last year I never realized that I could use structs in C# like I do in Swift. Pretty cool, thanks.

Jon

···

On Mar 7, 2016, at 6:15 PM, Dave Abrahams <dabrahams@apple.com> wrote:
on Mon Mar 07 2016, Jon Hoffman <hoffman.jon-AT-gmail.com <http://hoffman.jon-at-gmail.com/&gt;&gt; wrote:

On Mar 6, 2016, at 11:53 PM, Dave Abrahams <dabrahams@apple.com> wrote:
on Sun Mar 06 2016, Jon Hoffman <hoffman.jon-AT-gmail.com> wrote:

--
-Dave

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

I stand corrected; I neglected to think about using the enumeration.

Note again: there are other ways, e.g. you can make it immutable or
build it with COW.

So for the last two hours or so I put myself on a task to create a
mutable linked list using value types and to do it in an elegant way
(Hey I love challenges and beating my head against the wall).

A linked list that conforms to MutableCollection with the right
efficiency characteristics for linked lists *and* value semantics is a
tough problem.

I think under the proposed new indexing model you can just build it on
top of an Array, though ;-)

While I have found one working solution so far it is pretty ugly
therefore I have to ask myself, that even though it is preferred that
we use value types overall, should it be preferred that we use
reference types for mutable data structures like this?

What do you mean by “like this?” Array is a mutable data structure; is
it “like this?”

You're going to use reference types in the *implementation* of any type
that has arbitrary growth. Array uses a reference internally.

Trust me, I have not giving up finding an elegant solution yet just
wondering your thoughts on that.

My feeling is that linked lists are almost never the best answer in
real programs, but if you *really* need their characteristics you
might want to implement them with reference semantics.

···

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

On Mar 7, 2016, at 6:15 PM, Dave Abrahams <dabrahams@apple.com> wrote:
on Mon Mar 07 2016, Jon Hoffman <hoffman.jon-AT-gmail.com <http://hoffman.jon-at-gmail.com/&gt;&gt; wrote:

On Mar 6, 2016, at 11:53 PM, Dave Abrahams <dabrahams@apple.com> wrote:
on Sun Mar 06 2016, Jon Hoffman <hoffman.jon-AT-gmail.com> wrote:

--
-Dave

So for the last two hours or so I put myself on a task to create a
mutable linked list using value types and to do it in an elegant way
(Hey I love challenges and beating my head against the wall).

A linked list that conforms to MutableCollection with the right
efficiency characteristics for linked lists *and* value semantics is a
tough problem.

I think under the proposed new indexing model you can just build it on
top of an Array, though ;-)

But where is the fun in using an Array? The greater the challenge, the more rewarding it is to overcome it :)

While I have found one working solution so far it is pretty ugly
therefore I have to ask myself, that even though it is preferred that
we use value types overall, should it be preferred that we use
reference types for mutable data structures like this?

What do you mean by “like this?” Array is a mutable data structure; is
it “like this?”

You're going to use reference types in the *implementation* of any type
that has arbitrary growth. Array uses a reference internally.

Actually we should be able to make a decent stack out of a value type without a reference type behind it. Something like this:

enum Stack<T> {
    case Empty
    indirect case Node(T, next: Stack<T>)

    mutating func push(value: T) {
        self = .Node(value, next:self)
    }

    mutating func pop() -> T? {
        switch self {
        case .Empty: return nil
        case let .Node(value, next: next):
            self = next
            return value
        }
    }
}

Can use it like this:

var stack = Stack<Int>.Empty
stack.push(1)
stack.push(2)
stack.push(3)
stack.pop()
stack.pop()

Trust me, I have not giving up finding an elegant solution yet just
wondering your thoughts on that.

My feeling is that linked lists are almost never the best answer in
real programs, but if you *really* need their characteristics you
might want to implement them with reference semantics.

True but linked lists, stacks and queues are good data structures to play with especially when demonstrating what data structures are and how they work.

···

On Mar 8, 2016, at 1:40 PM, Dave Abrahams <dabrahams@apple.com> wrote:
on Mon Mar 07 2016, Jon Hoffman <hoffman.jon-AT-gmail.com> wrote:

--
-Dave

You're going to use reference types in the *implementation* of any type
that has arbitrary growth. Array uses a reference internally.

Actually we should be able to make a decent stack out of a value type without a reference type behind it. Something like this:

enum Stack<T> {
    case Empty
    indirect case Node(T, next: Stack<T>)

     ^^^^^^^^

Uses a reference internally :)

Marc

So for the last two hours or so I put myself on a task to create a
mutable linked list using value types and to do it in an elegant way
(Hey I love challenges and beating my head against the wall).

A linked list that conforms to MutableCollection with the right
efficiency characteristics for linked lists *and* value semantics is a
tough problem.

I think under the proposed new indexing model you can just build it on
top of an Array, though ;-)

But where is the fun in using an Array? The greater the challenge, the more rewarding it is to overcome it :)

While I have found one working solution so far it is pretty ugly
therefore I have to ask myself, that even though it is preferred that
we use value types overall, should it be preferred that we use
reference types for mutable data structures like this?

What do you mean by “like this?” Array is a mutable data structure; is
it “like this?”

You're going to use reference types in the *implementation* of any type
that has arbitrary growth. Array uses a reference internally.

Actually we should be able to make a decent stack out of a value type
without a reference type behind it. Something like this:

enum Stack<T> {
    case Empty
    indirect case Node(T, next: Stack<T>)

    mutating func push(value: T) {
        self = .Node(value, next:self)
    }

    mutating func pop() -> T? {
        switch self {
        case .Empty: return nil
        case let .Node(value, next: next):
            self = next
            return value
        }
    }
}

Can use it like this:

var stack = Stack<Int>.Empty
stack.push(1)
stack.push(2)
stack.push(3)
stack.pop()
stack.pop()

Leaving aside the reference implied by "indirect," this type is not
mutable by parts.

You can build that same thing trivially with an immutable class; you just
lose the method syntax because our class methods aren't allowed to write
back to the original reference, so you end up with

  push(&stack, 1)

etc.

That's just a syntactic distinction The real /semantic/ distinction
between value types and reference types occurs when you are doing
mutation of just a part:

Trust me, I have not giving up finding an elegant solution yet just
wondering your thoughts on that.

My feeling is that linked lists are almost never the best answer in
real programs, but if you *really* need their characteristics you
might want to implement them with reference semantics.

True but linked lists, stacks and queues are good data structures to
play with especially when demonstrating what data structures are and
how they work.

Sure. But when you're demonstrating linked data structures, do they
need to be value types? Do you even want the complication implied by
the CoW that's needed?

···

on Tue Mar 08 2016, Jon Hoffman <swift-users-AT-swift.org> wrote:

On Mar 8, 2016, at 1:40 PM, Dave Abrahams <dabrahams@apple.com> wrote:
on Mon Mar 07 2016, Jon Hoffman <hoffman.jon-AT-gmail.com> wrote:

--
-Dave

So for the last two hours or so I put myself on a task to create a
mutable linked list using value types and to do it in an elegant way
(Hey I love challenges and beating my head against the wall).

A linked list that conforms to MutableCollection with the right
efficiency characteristics for linked lists *and* value semantics is a
tough problem.

I think under the proposed new indexing model you can just build it on
top of an Array, though ;-)

But where is the fun in using an Array? The greater the challenge, the more rewarding it is to overcome it :)

While I have found one working solution so far it is pretty ugly
therefore I have to ask myself, that even though it is preferred that
we use value types overall, should it be preferred that we use
reference types for mutable data structures like this?

What do you mean by “like this?” Array is a mutable data structure; is
it “like this?”

You're going to use reference types in the *implementation* of any type
that has arbitrary growth. Array uses a reference internally.

Actually we should be able to make a decent stack out of a value type
without a reference type behind it. Something like this:

enum Stack<T> {
   case Empty
   indirect case Node(T, next: Stack<T>)

   mutating func push(value: T) {
       self = .Node(value, next:self)
   }

   mutating func pop() -> T? {
       switch self {
       case .Empty: return nil
       case let .Node(value, next: next):
           self = next
           return value
       }
   }
}

Can use it like this:

var stack = Stack<Int>.Empty
stack.push(1)
stack.push(2)
stack.push(3)
stack.pop()
stack.pop()

Leaving aside the reference implied by "indirect," this type is not
mutable by parts.

I was responding to your statement that we needed reference types in the implementation of any type that has arbitrary growth. I wasn’t implying that the individual parts were mutable :). I do understand that using indirect causes the value to be stored indirectly but that is how we create recursive value types.

You can build that same thing trivially with an immutable class; you just
lose the method syntax because our class methods aren't allowed to write
back to the original reference, so you end up with

push(&stack, 1)

etc.

That's just a syntactic distinction The real /semantic/ distinction
between value types and reference types occurs when you are doing
mutation of just a part:

Trust me, I have not giving up finding an elegant solution yet just
wondering your thoughts on that.

My feeling is that linked lists are almost never the best answer in
real programs, but if you *really* need their characteristics you
might want to implement them with reference semantics.

True but linked lists, stacks and queues are good data structures to
play with especially when demonstrating what data structures are and
how they work.

Sure. But when you're demonstrating linked data structures, do they
need to be value types? Do you even want the complication implied by
the CoW that's needed?

They absolutely do not need to be value types however sometimes it is fun to challenge yourself to see if you can figure out how to do something. Who does’t love a good challenge :). I probably would not use these for anything in production but the exercise and challenge itself can be fun. I wasn’t even aware that we could make recursive value types until you correctly me earlier in this e-mail chain when I said we couldn’t do it. The reason I was not aware that we could do recursive value types is because they are not something I would really use but since you mentioned that I could create them, I wanted to see what I could do with them.

Jon

···

On Mar 10, 2016, at 7:05 PM, Dave Abrahams via swift-users <swift-users@swift.org> wrote:
on Tue Mar 08 2016, Jon Hoffman <swift-users-AT-swift.org> wrote:

On Mar 8, 2016, at 1:40 PM, Dave Abrahams <dabrahams@apple.com> wrote:
on Mon Mar 07 2016, Jon Hoffman <hoffman.jon-AT-gmail.com> wrote:

--
-Dave

_______________________________________________
swift-users mailing list
swift-users@swift.org
https://lists.swift.org/mailman/listinfo/swift-users