[swift-users] Comparing POP to OOP

[Wallacy]

If you go further, you will realize that Objects are only Structures with
some function pointers.

The differences on structured programming and object-oriented programming
can be reduced to a "syntax level" too.

POP for example encourages more use of multiple (inheritance|composition)
than OO. The pattern is more important than syntax.

However I agree, Swift POP still have many limitations and almost no
innovation. There are several proposed improvements to protocols that
should arrive in the next versions, maybe then people start to consider POP
a true paradigm. For now is just a syntax sugar for *Composition over
inheritance*.

Em qua, 17 de fev de 2016 às 01:35, Daniel Tartaglia via swift-users <
swift-users at swift.org> escreveu:

> And your example is exactly equivalent to the below:
>
> protocol TestProtocol {
> var num1: Int {get set}
> var num2: Int {get set}
> }
>
> func doMath(t: TestProtocol) -> Int {
> return t.num1 + t.num2
> }
>
> struct MyTypeOne: TestProtocol {
> var num1 = 1
> var num2 = 2
> }
>
> struct MyTypeTwo: TestProtocol {
> var num1 = 1
> var num2 = 2
> func doMath() -> Int {
> return num2 - num1
> }
> }
>
> var one = MyTypeOne()
> var two = MyTypeTwo()
>
>
> print("MyTypeOne: \(doMath(one))")
> print("MyTypeTwo: \(two.doMath())")
>
> var t: TestProtocol = two
> print("TestProtocol \(doMath(t))")
>
> What the protocol extension gives you, all that it gives you, is a
> different syntax for doing the exact same thing. Where your code shines
> IMHO is when you want to then use the return value as a parameter to yet
> another function.
>
> two.doMath().handleResult() is far cleaner, and better expresses what is
> happening, than handleResult(doMath(one))
>
> All IMHO of course.
>
> On Feb 16, 2016, at 9:28 PM, Jon Hoffman <hoffman.jon at gmail.com> wrote:
>
> You are correct that if you are using the protocol type to interact with
> the instance then the method defined in the protocol extension will be
> called however if it is type casted to a concrete type which has a method
> that overrides the method in the protocol extension then the method in the
> concrete type would be called.  This following code illustrates this:
>
> protocol TestProtocol {
>     var num1: Int {get set}
>     var num2: Int {get set}
> }
>
> extension TestProtocol {
>     func doMath() -> Int {
>         return num1 + num2
>     }
> }
>
>
> struct MyTypeOne: TestProtocol {
>     var num1 = 1
>     var num2 = 2
> }
>
> struct MyTypeTwo: TestProtocol {
>     var num1 = 1
>     var num2 = 2
>     func doMath() -> Int {
>         return num2 - num1
>     }
> }
>
> var one = MyTypeOne()
> var two = MyTypeTwo()
>
>
> print("MyTypeOne: \(one.doMath())")
> print("MyTypeTwo: \(two.doMath())")
>
> var t: TestProtocol = two
> print("TestProtocol \(t.doMath())")
>
> The output from this code would be:
>
> *MyTypeOne: 3*
> *MyTypeTwo: 1*
> *TestProtocol 3*
>
> This shows that when calling the doMath() on the MyTypeTwo instance calls
> the method defined in the MyTypeTwo structure however if we call the method
> on the same instance but it being typecast as the protocol will call the
> method in the protocol.
>
> For the most part we would access the types though the interface provided
> by the protocol however using the “is” keyword we can check if a type is an
> instance of a particular concrete type or use the typecast operator to
> downcast the instance.  This would give us access to the method that is
> defined in the concrete type.  This can certainly be useful in certain
> situations.  I do agree that these situation should be avoided however it
> is something that can be done which we can not do with global functions.  I
> was just trying to list some of the differences between protocol extensions
> and global functions. Honestly, and this is my personal opinion, I believe
> there is significant difference between protocol extensions and global
> functions:  avoiding the global scope, using constraints, better code
> organization to name a couple, overriding, self parameter, better code
> manageability just to name some of them.
>
> Protocol Extensions are there so we can add functionality to a group of
> types that conform to a specific protocol that meets any constraints
> defined by the extension.  This allows us to avoid duplicate code similar
> to what we did with super classes in the OOP world.  However with protocols
> we can create very specific protocols rather than large monolithic
> superclasses.  Without protocol extensions we would have to revert to
> creating global functions however, in my opinion once again, the protocol
> extensions is a better option.  That is what I was trying to get across.
>
> Jon
>
>
> On Feb 16, 2016, at 8:30 PM, Brent Royal-Gordon <brent at architechies.com>
> wrote:
>
> We can override functionality provided from a protocol extension if we
> need specific functionality for a particular type.
>
>
> No you can't. Protocol extension methods (that is, methods declared only
> in an extension, as opposed to default implementations, which are both
> declared in the protocol and defined in an extension) are statically
> dispatched, so calling them on the protocol witness will always use the
> extension's implementation, even if some concrete type conforming to the
> protocol has a different implementation with the same name and signature.
>
> (I've worked on a proposal in the past that would require keywords to make
> this behavior clearer, but I've had trouble getting it through.)
>
> In any case, I'm pretty sure that's what Daniel means when he says
> extension methods are exactly equivalent to global functions. Sure, they
> appear after a dot, have an implicit self parameter, and are scoped to a
> particular type, but there's nothing dynamic about their behavior—they're
> not overridable in any useful sense.
>
> --
> Brent Royal-Gordon
> Architechies
>
>
>
> _______________________________________________
> 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/20160217/bc084ec3/attachment.html>