SLN SLN - 1 year ago 79
Swift Question

Is this a correct example to show the benefit of the protocol-oriented design of the Swift?

This question may be very wrong, and the result I would like to achieve may also very unclear. I'm a programming starter, please correct my wrong understandings. By your correction, I would learn a lot.

At 06:00 of the Session 408 video of WWCD15, One of the three major Beefs of classes complained by Crusty is "Automatic Sharing!" The protocol-oriented characteristic of the swift can solve the problem nicely.

And here is the code I wrote for self-study

protocol pooPro {
var a: Int { get }
var b: Int { get }
var c: Int { get }


extension pooPro {
func pooFun() -> Int {
return(a + b + c) //Function A

struct bluePrint: pooPro {
var a: Int
var b: Int
var c: Int

func pooFun() -> Int {
return(a * 10 + b * 10 + c * 10) // Function B

let byBluePrint = bluePrint(a: 1, b: 2, c: 3)
print(byBluePrint.pooFun()) // #1 Use Function B

let byProtocol: pooPro = byBluePrint // #PassingValue
byProtocol.pooFun() //#2 Use Function A

object of the type
invokes the Function B when
has been called; The
object of the type
is assigned to
object of the type
, but it doesn't bring the Function B to
, there fore the
object invokes the Function A when
has been called

This is because the property or method that gets invoked is dependent on the context of the type declaration. This is amazing! (Part A)

Question1: What is the mechanism behind it (Described in Part A), how Swift did that? It may need some compiling knowledge and might be too much for a beginner, But I'm just curious and I want to know

Question2: Is the code shown here has something to do with the video I pointed out in the beginning? In another word, is this a correct example to show the Swift's protocol-oriented properties solved the "Automatic Sharing" problem in traditional OO

Thanks a lot for your kind help and time.

Rob Rob
Answer Source

You've shared an example where you cast an instance of a struct back to the protocol, when you call the method, it calls the protocol extension implementation rather than the struct implementation.

I personally wouldn't worry too much about the precise internal mechanisms Swift employs with this protocol extension, but rather I'd suggest you just note the behavior. But equally important, note that if the protocol declared pooFun to be part of the protocol requirements, then suddenly the behavior changes and the struct implementation is called even if you cast it back to the protocol type before calling the method.

Personally, I took this portion of the video as a cautionary note regarding some idiosyncratic behavior of protocol extensions rather than anything to be celebrated. I wouldn't want to write code dependent upon this particular feature as the intended behavior is not self-evident when reading the code.

... is this a correct example to show the Swift's protocol-oriented properties solved the "Automatic Sharing" problem in traditional OO

No, this is not good example of solving the "Automatic Sharing" problem. This sharing problem is solved through the use of value type.

The purpose of protocol extensions is merely to provide shared implementation and a customization point. In other words, it's showing how to implement an inheritable and/or overridable behavior while enjoying the benefits of value type.

Recommended from our users: Dynamic Network Monitoring from WhatsUp Gold from IPSwitch. Free Download