Bob Lee Course Part 2 (lessons 4 to 5)
Moving on with Bob's course. Like I said, I enjoyed the last part as it did help to explain optionals - even though he was waffly and not always clear. Still, going to crack on with the next one.
Start Time - 19:28
Optional Chaining
*This time I'm going to create an Xcode playground to code along with the lesson.
Start Time - 19:28
Optional Chaining
*This time I'm going to create an Xcode playground to code along with the lesson.
let labelColor = UILabel().highlightedTextColor?.cgColor
So this is an example of an optional in action.
*I can just copy this from the course website - save some time!
class Human {
var name: String
init(name: String) {
self.name = name
}
func sayHello() {
print("Hello, I'm \(name)")
}
}
class Apartment {
var human : Human? = nil
}
What we're showing in the Apartment class is that the human value is of the Human class but could have the value of nil (an optional).
var dubaiApartment = Apartment()
dubaiApartment.human
In this one, the human property does exist but is worth nil.
dubaiApartment.human?.sayHello()
Now this is interesting - the ? automatically gets put in!
var dubaiApartment = Apartment()
dubaiApartment.human?.name
dubaiApartment.human = Human(name: "Josh")
let name = dubaiApartment.human?.name
So we still need to unwrap the value. The value of name is still an optional String, So to unwrap it we can FORCE unwrap with the ! instead of the ? in the above line. NOT SAFE though! If I changed the value to nil then the program would crash!
if let theName = dubaiApartment.human?.name {
print(theName)
} else {
print("No name is there")
}
That's the implicit unwrapping - that's all good.
Some good stuff here - never noticed that the ? gets automatically put in; that makes sense as the unwrapping hasn't happened yet! Next lesson - guard statements...
Guard and Defer Statement
Guard statements - these promote emptiness! Well, that sounds pompous but what it really means is that it goes to the 'nil' block first.
The point Bob next makes is that with multiple values, there would be LOTs of if statements and bocks of code used.
let iCanDrink = false
func checkDrinkingAges() {
guard iCanDrink else {
print("You can't drink")
return
}
}
So in this example, the guard statement goes straight to the else with the print statement, then return. The return means you exit out of the function. No more code can follow that. So in the above example, if iCanDrink is true, then you ignore the rest of the code in the block.
let iCanDrink = false
func checkDrinkingAges() {
guard iCanDrink else {
print("You can't drink")
return
}
print("You are allowed to drink")
}
checkDrinkingAges()
This is the entire function. So a guard else is NOT for multiple options. Realised something else - that last print line isn't even needed - it will work without it, just nothing will be outputted to the console. Only the error message will come up!
OK - now multiple values!
This is the 'nightmare scenario'....
I can see why! Trying to negotiate this many looks pretty hideous.
Now this works but there is a much more concise way. Doing it with the guard let statement is a little better but still verbose.
Here are some more values - all f1 related!
var driverName: String? = "Fernando Alonso"
var driverCar: String? = "Renault"
var driverWins: Int? = 32
func unwrap() {
if let name = driverName, let car = driverCar, let wins = driverWins {
print("Driver is \(driverName), who drives for \(car) and has won \(wins) races")
} else {
print("Error")
}
In this case, the print statement relies on no errors being made in the typing of it all, which is not so easy!
func guardUnwrap() {
guard let name = driverName, let car = driverCar, let wins = driverWins else {
print("something is missing")
return
}
}
So the guard one is definitely simpler.
Can add it in with the print statement for where the values are there:
func guardUnwrap() {
guard let name = driverName, let car = driverCar, let wins = driverWins else {
print("something is missing")
return
}
print("Driver is \(name), who drives for \(car) and has won \(wins) races")
}
So that's a defer statement. Don't really know about that yet.
That is all for now! Some good stuff again - a little clearer than before. Thanks Bob! Will be back tomorrow!
Comments
Post a Comment