Chapter 23 challenges

📚 Official Books Swift Apprentice
1

Spoiler alert: This question reveals the answer to the challenge, so if you haven’t done it yet, you shouldn’t read this!

I did the challenges in chapter 23 and could break the strong cycle references in the 2 exercices. My question is to better understand the solution offered by the author.

In the code for Challenge A, you have a Person and Car. The Person has reference to a Car var car: Car? and Car has a reference to Person var owner: Person?

My solution was to change the property in in the Person class (to weak var car: Car?), which broke the cycle. But the suggested solution was to change the property Car to: weak var owner: Person?.

Is there any particular reason why that is? Is it better? Logically, I was thinking that a car always have an owner (a functional car at least), but a person doesn’t necessarily have a car. What are the impacts of this kind of decision?

Thanks

2

I’m the actual author of this specific and particular chapter and challenge from the book. Your solution and logic behind it is also fine as well after all for sure and for good indeed. My solution though relies on the fact that brand new cars don’t have any assigned owners yet (a new car is also a functional and working car after all :]), so as you can see there are certain cases like this very particular one when the car’s owner can also be modelled as a weak reference as well after all.

Note: I have actually changed the challenge’s solution in the chapter’s playground based on your valuable and excellent feedback in the chapter’s updated book version for Swift 4. Thank you for pointing out the whole thing after all in the first place and to begin with - much appreciated. :]

1 Like
3

I disagree with this solution.

Reason: reference values linger on the object even after the instance’s property referencing it has been set to nil (I think this is what is happening, please correct me if I am wrong)

all owner’s properties are nil, regardless of car’s properties

owner = nil

// Cosmin: ALL PROPERTIES SHOULD BE NIL - OK!
if let owner = owner {
    owner.name          // nil
    owner.email         // nil
    // Cosmin's car
    owner.car!.id       // nil
    owner.car!.type     // nil
    owner.car!.owner    // nil
}

weak var car: Car?

// Car: OWNER SHOULD BE NIL - NOT OK!
if let car = car {
    car.id             // 10
    car.type           // BMW
    car.owner?.name    /* still has Cosmin! */
}

Solution!
weak var owner: Person

// Car: OWNER SHOULD BE NIL - OK!
if let car = car {
    car.id             // 10
    car.type           // BMW
    car.owner?.name    /* nil */
}

I had a similar issue with the second Challenge

Solution:
weak var account: Account? as well as unowned let customer: Customer

account = nil

// Account: ALL PROPERTIES SHOULD BE NIL - OK!
if let account = account {
    account.number
    account.type
    account.customer.name
}

var account: Account? & unowned let customer: Customer

// Customer: CUSTOMER ACCOUNT SHOULD BE NIL - NOT OK!
if let customer = customer {
    customer.name               // George
    customer.email              // george@what...
    customer.account?.number    /* still has 10! */
}

weak var account: Account? & unowned let customer: Customer

// Customer: CUSTOMER ACCOUNT SHOULD BE NIL - OK!
if let customer = customer {
    customer.name               // George
    customer.email              // george@what...
    customer.account?.number    /* nil */
}

I’m new, still learning, which is why I broke each instance down to see each property as values were changed.
But man, this was AN EXCELLENT TUTORIAL!!! WOW Brilliant stuff. I cannot thank you enough.
You made these incredibly complex concepts really easy to learn!

I usually spend anywhere from 8-10 hours per chapter, note taking practicing, disecting, and improving on previously learned concepts. I specifiically love learning more about closures. They are by far my favourite thing in Swift so far.

And your deinit print outs were brilliant. I think they were in the Advanced classes chapter too, which again was a REALLY difficult chapter, but I was able to grasp it - classes were so confusing before I read your tutorials, I’m not too confident about using them yet - I prefer structs, but I know that if I keep reviewing and practicing from your text I’ll get there!!!

In classes - the hardest concept was the conveinience init, but looking back on it today, I realized that they are supposed to do the super init for you? An instance of it’s superclass type is passed in and then within the init it does what a super.init does but does it specifically on the parameter name - since it now has the properties of it’s superclass.
And you use a Convenience init over a Designated init when you don’t want the init you are creating to handle the init of it’s stored properties - so you call a designated init to do that for it. Please let me know if I am wrong about any of this! I am a student of Swift
Anyway. THANK YOU!!!