[MUSIC] Okay now that again we’ve gone one more step in defining the city classes and most objectives we see in Swift, what is next? What else can we showcase the difference between these two languages? >> So we’re going to show something a bit more interesting, a function. A method of a class, of our city class. And we're also gonna create our country class which we had put off till now. So I mean, what method makes sense for a city? None of them. We have to creat our country class. >> Yeah. So, that's right. So, the city class is pretty basic. It just holds a population and a name. I mean, we could add more stuff to that at some point if we wanted to. But, for now, we'll just keep it straightforward. It's just a data dump for our names and populations. So, but we're gonna store those city classes in a country. Country's gonna hold a bunch of cities. So it's gonna have an array of cities, and the country itself has a name as well. So the country has to initialize itself with a list of cities. And then we can do things on that like find the biggest city, or find the particular city with a particular name. So we'll need to create a method on the country to kind of search through its cities for the kind of city that we want. We could, you know, do all sorts of stuff with the country object eventually. >> Yeah, and so I'm basically going through the same things we've done already in this module. It's a good, use this as a nice review, but in here we're gonna create a UTCountry. And again, the UT prefix, to make sure that our country is our country. >> Yeah, so we don't override somebody else's country class that was maybe created somewhere else. >> Yes, and we also don't want anyone else overriding our country class. >> Yeah, eventually. >> That guy is very important. And there is one interesting thing, I guess, here which is the cities array. And you'll see very soon right now that here, we're using an array of City, which we've seen before. And it's a Value type, holding an array of cities, where here, we're using an NSArray, which is Objective-C's class for any kind of array really. And it can store anything you want as long as it's an object. >> Yeah, that's right. And are you doing assign there, or strong? >> It should be strong. >> I think it's strong [LAUGH], cuz array is also a reference to an array, not an actual value of an array. Really that's important that the Objective-C collection types can store any Objective-C object. But they can't store numbers, it's just very interesting. So you can create an array of integers in Swift. Because that's totally, an integer, is a type that can be stored in an array. But in Objective-C, you would have to box that integer into an object, like a NS number. Or some kind of like specialized object for storing that number. You can't store regular integers in an array. You can only store objects, basically anything that would be referenced by an ID or a class star kind of variable. >> Now as you were talking, Jack, you were talking a little ahead. So perhaps first of all, that point is very useful. And it shows that Swift, a lot of things have become perhaps a little simpler and more obvious for users who've used Java, for example, before. But what did you just type? So- >> Yeah, so here in object we define the country in Swift, and here is the country in Objective-C. And it's very similar to the city except for what we were just talking about, the rate hike, which is many cities which is very different from the city, city array we see in Swift. And then everything else is pretty much the same as the city itself. And here we have the initializer, which now takes in a city instead of a population. >> So, essentially the code on the right is the exact implementation in Objective-C on the Swift code out on the left. >> Mm-hm. Which we covered in the previous section. So, here we're going to add a method. So, we were going to maybe find a city, return a city by name? >> Yeah. So, maybe my user taps a city in a list, and then you wanna get more information about that city, maybe the population of the city. So you have to go to your model object that we're doing here and find that particular city. And we would look it up by name, which would be the easiest way right now, I guess. >> That makes sense. So it would be find city with name, and then we pass in name string. There are probably better ways in Swift to do this, as we covered in the standard library, ways you can search through a string. But here to show comparisons with Objective-C, we're just going to iterate through the array and do string comparison on all the names. >> And ultimately, if it works it works, right? >> Yeah. >> [LAUGH] You can get fancy with a single line of code. But sometimes a for loop is just less mental gymnastics, so [LAUGH]. >> I agree. >> Yeah. >> Oh, and just something that we totally missed here. >> Yep. >> This is the return bad, return type. This should give you a city, but an optional city because it might not, the name you're passing may not be in our cities already. So if we find it we're gonna return the city, if we don't find it, we're gonna return nil. >> Like, if I'm looking for Tokyo but my country is Canada. You would wanna return nil just to indicate that that city doesn't exist in Canada basically. >> Yes. And we covered that in our optionals, so you should know that. And in Objective-C, the same function is gonna look a bit weird. FindCityWithName, my bad, it's called a UTCity. [LAUGH] And we're going to do a similar thing. >> And don't forget the brackets there. [LAUGH] You're doing pretty good switching back and forth and talking at the same time. It's pretty impressive. >> [LAUGH] Name is equal to string. And that's a very clear way of specifying who you want. [LAUGH] Return city. >> So if we just said if city equals name, what we would be comparing there would be the pointers, and that would may or may not work but it's not what we're actually trying to test. We want to test the quality of the actual string, so in Objective-C there is a function, or a method, that is called isEqualToString which will actually compare the two strings. In Swift, because string is a value type, when you say equals equals or compare, you actually are comparing the actual value of the string between the two symbols there. >> Yeah, like we covered in value type versus reference types. When you compare value types, you want to compare their meaning. If they represent the same thing, then they're just saying, object, they don't have to be the actually same, created at the same time. Where as in object, if you're comparing the pointers, then they're pointing to the same location in memory, which is the same exact object. >> Yeah, which is not we wanted to compare, because that name could come from anywhere. Somebody could have typed it in, who knows, right? So we wanted to compare the actual string, not the pointers. Objective-C, you have to be careful about that distinction here. >> Mm-hm. So is there anything that looks weird to you here, Parham? >> I think it's fairly straightforward. The one observation is that, again, look at how simpler it is to create the same function or the same effect in Swift versus Objective-C. So, really, Swift does make life a lot easier to use. >> Yeah. We're not even done with Objective-C yet because right now this method is only in our implementation. So, no one else can even see it. >> One nice thing about the Swift one as well is in the method signature there it indicates that it may return nil. So, anybody who looks at that and tries to use that function has to test for nil. Where as, if somebody naively uses our Objective-C version, they may not realize it could return nil and they may get into trouble at some point later in their code. >> Yes because in this case it makes sense to return optional. In other functions where it doesn't make sense to return optional, for example, if we ask for the city with the most people and it's always gonna be a city with the most population, right? >> Unless there's no cities. >> Unless there's no cities, which we're not gonna consider. Because our city. Well, I guess that's true. >> I guess there could be a country with no cities. >> Yes. >> Antarctica maybe. >> [LAUGH] Is that a country? >> No. Let's not get into geopolitics. >> Yes. But say there was no way it could do that. Then in Swift, we could let the user of the function know by not returning an optional. Whereas, in Objective-C, we would still return it as point utility, a UTCity. Which, even though it could never be nil, it could be nil [LAUGH]. We could say that nil- >> Yeah, we could make a mistake in our code, for example, and- >> And it'll be nil. >> The compiler wouldn't catch it, for example. Whereas, Swift, if we If we remove that return nil, for example, at the bottom there, it's gonna give us, it's actually gonna warn us, you know, that missing return, so- >> Yes, yep, very good points. And again, so back to Objective-C, which is already a bit more code than Swift is. We then have to copy this function. We have to declare this function in the header file to make sure that other parts of our code can see it.
