[MUSIC]                         
Stanford University.            
>> All right,                   
well, welcome to                
Lecture number four?            
No. Yes, four of                
Stanford CS193P, Fall of 2017.  
Today, we're gonna continue     
to talk about Swift.            
This will be the last we talk   
about Swift. After this,        
we're pretty much gonna         
kinda assume you know Swift.    
Obviously you'll be learning    
on the fly as you go, but       
starting next week,             
we're gonna dive right          
into iOS, UI kit and            
all that. So I'm gonna do the   
quick demo that I postponed     
from Wednesday of this          
mutating keyword that we have   
to add when we make something   
a struct versus a class. Then   
we're gonna talk about two      
very important topics today.    
Protocols and closures.         
Functions as types of general   
those two and in between, I'm   
gonna talk about string which   
is important in a way but       
it's not like the monstrous     
important topics like           
prototypes and closures are.    
So start right into that demo   
that I had. And remember, we    
were talking at the time about  
making things a struct and      
that it's a little different    
then a class because that copy  
on write. Swift needs to know   
when a function might           
actually modify the thing so    
that it knows to actually       
make a real copy. So            
let's go back here to our app,  
Concentration, where we were.   
Let's go to Concentration,      
which if you recall,            
we made be a class.             
A class Concentration. And      
this could have just as         
easily been a struct.           
I really made it a class        
just so when we're doing        
the initialize and stuff,       
you could see the difference    
between Concentration and card  
because card was a struct and   
Concentration was a class.      
But there's                     
no reason Concentration         
wouldn't have been a struct.    
It's probably, it might even    
be better as a struct here.     
Now we don't pass               
Concentration games around and  
all that, it just kinda         
sits in our controller.         
Not really a pointer to our     
model but this would embed      
the model there. So it doesn't  
really matter too much.         
But when I change this from     
class to struct, notice here    
that I get an error. And let's  
scroll down and here they are,  
here's the error and            
this error is saying,           
cannot assign to property,      
self is immutable. Why is this  
saying self is immutable? I'm   
trying to change the card here  
to say that they've match,      
for example.                    
Well, self is immutable         
because this function right     
is not marked mutable, and so   
it is assumed to not mutate,    
not change this                 
Concentration object. So        
of course we need chooseCard    
to change the Concentration     
object cuz it's the main        
thing. The change of the game,  
so all we need to do is add     
mutable right here, that        
marks, sorry, mutating, not     
mutable, you add that here and  
that says that this is          
a mutating function,            
all the errors go away,         
and we're all good to go.       
Question?                       
>> [INAUDIBLE]                  
>> Okay, the question is why    
does this not need it?          
This is a var. And              
this var is get and set, so     
Swift already knows this is     
mutating, cuz it's settable.    
If this was get only, then      
it wouldn't be mutating and     
Swift would know that.          
So for vars, Swift knows. And   
if it's not a computed var,     
like look at this var,          
how does this one know? That's  
because, well, this one is      
read only externally but        
for us it's writable. Here,     
anything that's a var it        
assumed it's writable. If it    
were a let, a let, then it      
would think it's not writable.  
So that's how you do mutating,  
or mutable. If for vars is      
whether they're vars or let,    
or for computer property,       
whether it has both get and     
set. Where we got all that? So  
it's only funcs that we         
have to put that on.            
Yeah, question.                 
>> [INAUDIBLE]                  
>> Yes, so the question is,     
why is this you need to a       
struct and not a class, why do  
I need to struct? And that's    
very important to understand,   
very good question. Structs     
are value types, not reference  
types. So structs don't live    
in the heap. As we pass         
the struct around since it's    
a value type, it gets copied.   
Constantly copied everywhere.   
Pass through a function,        
a copy is made. Put in a var,   
a copy is made. Well,           
soon, that would be incredibly  
inefficient if it actually      
copy the bits of this entire    
thing every time. So instead,   
Swift is smart. It only         
actually copies the bits when   
you mutate it. That's called    
copy-on-write semantics.        
This is why structs             
are different,                  
because they have that          
copy-on-write semantics.        
A class doesn't have that, cuz  
when you pass a class around,   
the class just lives            
once in the heap,               
and you're passing              
pointers to it around.          
And there could be 20           
pointers to the same object.    
Totally different kinda model   
for memory. So that's why,      
it's because it's a value type  
that copy on writes stuff,      
that's why we care              
that it's mutating.             
Let's go back to our slides     
and talk about the first very,  
very important topic            
today which is protocols.       
It's the fourth pillar of       
building data structures        
inside of Swift. You already    
know a lot now about class,     
struct and enum. And            
a protocol is something where   
its a very simple concept.      
A protocol is basically just    
a list of methods and vars      
with no implementation. But     
it's the use of having          
protocols. It's so              
pervasively used throughout     
the Swift language and          
the runtime that makes it so    
powerful. So first I'm just     
gonna go through a little bit   
of why we have protocols.       
Then I'll show you              
the syntax of protocols.        
What it looks like to type in   
a protocol and define one.      
Then we'll start talking        
about the use of protocols.     
Where do we use them?           
Why are they so valuable? So    
let's start with,               
what protocols are all about?   
Protocols are essentially       
a way for                       
callers to call an API          
with anything they want.        
Any struct, enum, class,        
it can pass anything they       
want in. And at the same time   
the receiving method can        
specify what it really wants.   
So both sides get to do what    
they want. The receiving thing  
gets to say what it wants       
the thing you're passing and    
to do and the thing passing in  
can pass whatever it wants as   
long as it does that thing.     
And to do all this all          
a protocol is, is a list        
of vars and functions.          
That's all a protocol is.       
It's just a list of them.       
Not an implementation or        
anything, just a list of them.  
And it's how we use them in     
the API that let's us get this  
behavior of having              
the callers and the callees.    
Get to express things           
the way they want. Now, what    
are protocols good for? They    
make APIs very flexible and     
expressive, as                  
you're going to see.            
They're super good for blind    
structured communication.       
Like, remember back             
to my MVC talk.                 
The communication between       
the view and the controller.    
All those will, did, shoulds.   
And the data at count,          
those kind of communications    
between a view controller.      
That all had to be blind,       
because the views are generic   
and the controllers are very    
specific, and protocols is how  
we make that work. It's also    
great for mandating behavior,   
for example, in a dictionary,   
a dictionary's a hash table,    
raise your hand if you know     
what a hash table is when I     
say that. Okay, everybody.      
Good. So it's a hash table.     
So the keys of a dictionary     
clearly have to be hashable.    
You have to be able to get a    
hash value otherwise you can't  
hash them and put them in       
as keys of this hash table.     
Well, protocols let us define   
dictionary in a way so          
that we don't use any keys      
that aren't hashable.           
So mandating behavior           
passibility, for example,       
of the key it's great for       
that. It's also great for       
sharing functionality           
between very disparate types,   
types that you would never use  
object oriented inheritance to  
make them share a base class,   
but they are very similar, for  
example, string, array,         
countable range. They are all   
collections of things. Now      
they're completely different.   
Come one,                       
a countable range and           
a string are completely         
different. But they are both    
collections, a string is        
a collection of characters,     
accountable range is a          
collection of integers if it's  
an accountable range of int.    
So they do share some and       
protocols has a mechanism to    
allow you to share that kind    
of similarity without having    
to have all those thing         
inherit from some kind common   
base class that knows about     
collections of things. You      
see what I'm saying? And so     
in a way, protocols provide     
multiple inheritance. Now,      
since protocols are only doing  
the declaration of the vars     
and functions, there's no       
storage of, of those things,    
so there's no                   
inheritance of data,            
it's purely just                
inheritance of,                 
inheritance of functionality.   
All right, as I go              
through this explanation, it's  
super important to understand   
that protocols are just         
a type. Just like a class is    
a type, a struct, an enum,      
a protocol is a type.           
A first-class type, just like   
all the rest of these types,    
that's very important           
to understand.                  
All right, so let's dive        
into what a protocol is.        
There's three parts             
to a protocol.                  
One, there's the declaration    
of the protocol, just like you  
have a declaration of a class   
or an enum or a struct. For     
a protocol,                     
that's just a list of           
methods with their arguments    
and return values and           
a list of vars. That's it,      
that's what a protocol is,      
it's a declaration. Second      
part of a protocol though       
is a class or a struct or       
an enum raises its hand and     
claims to implement those       
methods in vars in that         
protocol. So there's the claim  
to implement a protocol,        
that's the second part.         
Cuz somebody has to actually    
implement those methods that    
the protocol is a list of, and  
that's classes, structs and     
enums, so they have to claim.   
And then the third part is      
the code in those classes,      
structs and in in enums         
that actually implements        
the protocol methods in vars.   
Okay, so                        
notice I'm mentioning vars.     
The vars,                       
the storage of the vars,        
if they're not computed vars,   
has to be in some struct,       
enum or a class. Because,       
that's the only places you can  
have any storage, all right?    
Okay, so that's it, those are   
the three parts of a protocol.  
Now I'm gonna take              
a little aside, and             
not even gonna spend too        
much time on this, but          
all the methods and vars in     
a protocol are mandatory.       
If you're wanna                 
raise your hand and             
say, I implement                
this protocol.                  
If you're a struct or enum or   
a class, you have to implement  
all of the methods and all      
the vars in Swift. However,     
in Objective-C, that was        
not true. In Objective-C,       
protocols could have            
optional methods. Methods or    
vars in the protocol that you   
could choose to implement or    
not. Now, that's quite a big    
difference and the way Swift    
deals with that is it allows    
you to put @objc, in front of   
you declaration of a protocol   
to make it so that this         
is an Objective-C protocol      
instead of a switch protocol.   
And the only difference         
is that now,                    
methods inside of your          
protocol can be marked          
optional. Not optional like     
you know question mark,         
exclamation point,              
that kind of optional enum.     
I'm talking about optional      
like you can optionally         
implement the method but you    
don't have to implement if you  
don't want to. Okay, so that's  
a special kind of backwards     
compatibility mode              
to Objective-C, but             
in Swift, we don't do that. So  
the only time we're ever gonna  
have this going on in this      
class is when we're using iOS   
API that was designed back      
in the Objective-C world.       
Specifically, delegation,       
which is that blind view to     
controller communication.       
That is all Objective-C         
style protocols and so          
when you start using that down  
the road in the coming weeks,   
you're gonna see these          
protocols that are marked       
Objective-C and some of         
them are marked optional        
that you don't have to          
implement a method.             
That's not Swift. That's        
Objective-C compatibility.      
So just put that in             
the back of your brain so       
that when you see it, you're    
like, whoa. I thought I had to  
implement all the methods in    
your protocol. Yes, you do in   
Swift. Only this exception,     
all right, back to protocols.   
Okay, so how do we declare a    
protocol? What does the syntax  
look like? Well, it looks       
a lot like declaring a class.   
Protocol, SomeProtocol,         
SomeProtocol is the name        
of that protocol just like      
if you say at class whatever    
that would be the name          
of the class.                   
Notice that there's also        
colon, InheritedProtocol1,      
InheritedProtocol2 actually it  
can be any number of these.     
These are the other protocols   
that SomeProtocol inherits.     
Okay, so there is inheritance   
in protocols. It means          
a little bit different          
thing then in a class.          
Okay, inheritance in            
the protocol world means,       
if you wanna claim to           
implement some protocol. You    
also have have to implement     
InheritedProtocol1 and          
InheritedProtocol2. So it's     
almost like it's a mandatory    
additional protocols you must   
implement if you wanna say      
you implement this protocol.    
We call that protocol           
inheritance. We call it that    
because some protocol inherits  
the requirement to implement    
these other protocols. Now,     
once you go inside              
the definition of protocol,     
you can see there's no code.    
Protocols have no code,         
they are not implementations,   
they are purely declarations.   
And, in fact, when you declare  
that you're gonna have a var    
be part of your protocol,       
all you get to say is           
whether it's a read-only var,   
which would be get or           
a read-and-write var            
with get set like this.         
So this one right here some     
property would be get and set.  
So if you wanna implement       
this protocol, your class or    
struct and you wanna implement  
this, you would have to have    
a var that can be get and set.  
Okay, that's what that means.   
Any methods that you            
have in your protocol           
that might be implemented by a  
struct and modified the thing   
have to be marked mutating      
of course, right?               
Because again Swift             
needs to know oh                
this method might change        
the thing that implements it.   
Now there's a little trick      
if you want, if you know        
this protocol's never gonna     
be implemented by a struct,     
then you don't need the         
mutating. But you have to mark  
the protocol to say this is     
a class only protocol. You do   
that by saying colon class as   
the first thing right after     
the protocol declaration.       
You see how I put that yellow   
colon class up there? Okay,     
so then if you did that then    
you would not have to put the   
mutating because of course,     
you never have to put           
mutating in a class, but        
then this protocol could not    
be implemented by a struct.     
It could only be implemented    
by a class, we rarely do this.  
Okay we don't usually make      
a protocol, be restricted to    
a class and in fact 99% of all  
the protocols you're gonna see  
in iOS could be implemented     
by anybody. Okay,               
what else we got here. Yes,     
you can an even add an init to  
your protocol. And that means   
if you're a class or a struct   
that implements this protocol,  
you have to                     
implement this init.            
So, I have to be able to        
initialize you. So, that        
was how we declare a protocol,  
now let's look how a class or   
a struct says, raises his       
hand and says yes, I will       
implement this protocol. All    
it does is in a class after     
the superclass, you just say    
comma all the protocols you     
claim to implement. It's as     
simple as that, of course, for  
a struct there is               
no superclass, so               
you would just say enum or      
struct, whatever, colon         
the protocols you implement.    
Okay, so that's how you claim.  
This is you raising your hand   
and say I implement that.       
As soon as you say that the     
source compiler is gonna check  
to make sure you actually       
implement those methods and     
vars in that protocol. And if   
you don't, you're going to get  
errors. It's gonna say you do   
not implement this on protocol  
method whatever. And you're     
have to go do that, all right?  
You can do any number of        
protocols that you want.        
That's sometimes why we say     
that protocols can provide      
multiple inheritance because    
you can have as many of these   
ah, as you want going on        
there. Ah, by the way,          
if there is an init             
in the protocol and             
you're a class and you say,     
implement that protocol,        
you have to mark there,         
your init required.             
That's because you wouldn't     
want a subclass to come along.  
Subclass you, subclass that     
init away which is possible.    
It's possible to subclass and   
make it so                      
an init doesn't work anymore    
from your superclass.           
You don't want to allow         
subclasses to do that because   
then a subclass would no        
longer implement this protocol  
and yet people might think it   
does because it inherits from   
something that does. So, once   
a class implements protocol,    
all it's subclasses have to as  
well, so all init would have    
to be required.                 
Cuz init kind of special,       
in that it's possible in        
your subclass, to make it so    
you no longer implement         
a certain init with certain     
arguments. By the way, in your  
reading, there's a whole bunch  
about making inits in classes.  
It's probably                   
the most complicated long part  
of your reading for this week.  
You gonna have to fight         
through it cuz it's pretty      
complicated. Inheritance        
makes initialization really     
difficult because you've got    
your own vars, you've got your  
superclasses vars. You've got   
to get things initialized       
in the right order, all that,   
it's quite complicated.         
So, unfortunately one of the    
things the day you subclass     
can make it so you don't have   
to form an init anymore.        
So that's why you have to       
mark it required. One thing     
is you don't have to add your   
conformance to a protocol.      
You don't have to add           
all the methods, and            
vars in that protocol. In your  
actual class declaration, or    
your struct declaration you     
can add it with an extension,   
you know how we can extend      
Int to add arc4random.          
Well we could extend Int to     
conform to some protocol.       
Okay, that would                
be perfectly fine.              
We would just say               
extension Int :,                
the protocol we wanted int to   
implement and then in there,    
and the extension we would put  
all the implementations of      
the vars and                    
methods in that protocol. And   
this is actually quite common   
to use in extension just for    
code book keeping. Well some    
use an extension to implement   
a whole protocol. It's just     
nice groups it all nicely.      
Okay, let's see an example      
of using protocols like         
the type they are.              
Okay, protocols are types. So   
let's see, here I have          
a protocol called Moveable.     
It has one method in it         
called, move to, all right?     
And I've created a class        
called Car, which can be moved  
and another class called        
Shape, like triangle or         
square, which can also          
be moved. Now a Car and         
a Shape, incredibly different   
things and one is class and     
one is struct but both of them  
implement this same protocol.   
Okay, we're gonna see what      
it looks like in the code,      
when you have this              
kind of situation,              
which it's perfectly            
legal to do this. And so        
I've created a couple of vars   
down at the bottom there,       
a prius, which is a Car, and    
a square, which is a Shape.     
All right, now I'm going to     
declare a var, thing to move.   
It's gonna be of type           
Moveable. Remember I said,      
protocols are types. So I       
made thing to move be of type   
Moveable and assigned it        
to prius, is this allowed?      
Can I assign prius to           
the thing to move? Sure,        
because a prius implements      
the Moveable protocol.          
It implements that move         
to over there and it and        
it also claims to               
implement the Moveable. So      
this is a perfectly legal       
statement right here, but       
this has made a variable        
that is not of type Car, or     
something like that, it's of    
type Moveable. So, I can send   
messages like thingToMove.move  
that's perfectly legal, but     
I can not say                   
thingToMove.changeOil,          
even though a prius is a Car    
and Car implements changeOil.   
You see why I can't send        
that to thingToMove?            
Because thingToMove is          
a Moveable. It's not a Car,     
it's a Moveable. So even        
though the car that happens to  
be in that variable, it can do  
changeOil, I can't send it.     
Swift will not allow me to      
send that message because       
thingToMove in Swift's          
mind is just a Moveable.        
The only thing Swift knows      
that it can do is move to,      
right?                          
So this is the most important   
thing on this entire slide,     
is that red thing. You cannot   
do changeOil if you have a var  
which is of type thingToMove.   
But what are some things you    
can do? Well, I can say         
thingToMove equals square.      
Cuz a square is a Shape,and     
a Shape implements Moveable.    
I could even have an array of   
Moveable and put a prius and    
a square inside of it.          
Cuz even though a prius and     
square are completely           
different,                      
one's a struct, one's a class,  
one's a Car, one's a Shape.     
They're completely              
not really different,           
they can be in the same array,  
because they're both Moveable,  
you see that? And of course I   
can have functions that take    
Moveables as an argument.       
Here's slide,                   
which takes a slider, which     
is a type of Moveable. And      
inside I can say slider         
move to positionToSlideTo,      
and then I can call             
slide the prius,                
slide the square. Perfectly     
legal to say because those      
are Moveables. Yeah, question?  
>> Does that mean that move     
to function where Car and       
Shape have to do                
the exact same thing, or        
do they just-                   
>> You mean,                    
do the exact same thing like    
perform the same action? Okay,  
so the question is, does this   
mean that move to in Car and    
move to in Shape, do they       
have to do exact same thing?    
And the answer is, no. They     
can do anything they want.      
They can do whatever move       
to makes sense for a Car or     
whatever move to                
makes sense for                 
a Shape.                        
>> If you assign it to          
squares. And you call move to,  
how does it decide              
which move to to use?           
>> Okay, so                     
the question is if I declare    
this Movable protocol and       
then I say something            
are movable.                    
They are called move to, how    
does it know which one to use?  
Well, because Swift underneath  
knows which type it is, okay.   
When we say                     
thingToMove.something           
at that level we're             
the programmer and              
Swift is enforcing that         
it has to be a movable.         
But when it comes to actually   
executing the code now Swift    
looks and says, oh it's a Car,  
so I'm gonna use Car's moveTo.  
So Swift behind                 
the scenes is doing it.         
But the whole reason that       
we're typing thing to move      
to be of type thing to move     
is cuz we're telling everyone   
who's reading our code,         
I'm just using this thing as    
a Moveable thing.               
I don't care that it's a car.   
My code works on anything       
that's Movable. So              
I'm just communicating to       
people reading my code and      
to myself in all that but       
Swift under the covers          
of course knows which move to   
execute. It is possible by      
the way to have functions that  
take an argument that has to    
implement multiple protocols.   
So here the slipAndSlide is     
it's function it's argument x.  
Those things have to implement  
Movable and they have to        
implement something called      
slippery which is not shown on  
the slide. So now I cannot say  
slipAndSlide(prius) because     
while prius is Movable,         
it's not slippery. And so       
this would not be allowed,      
Swift would complain here. But  
that's how this &. That's how   
you make it so it requires      
multiple protocol conformists.  
So you're getting a feel for    
how we use a protocol init by   
declaring vars and              
arguments to functions. So      
it's only scratching            
the surface of protocols.       
Yeah, question.                 
>> [INAUDIBLE]                  
The thing to move [INAUDIBLE]   
square.                         
>> Yeah.                        
>> So when you                  
call function [INAUDIBLE]       
>> Here let me back up to       
Okay, so what was that?         
>> [INAUDIBLE]                  
>> Yeah.                        
>> [INAUDIBLE]                  
>> Yeah, up there.              
>> So when you call method on   
thingToMove. [INAUDIBLE]        
>> Okay, so he's saying,        
look, I set thingToMove to be   
a prius. Then I call move to,   
which one did it do?            
Obviously the prius. Then I     
set thingToMove to be square.   
Now if I called move to,        
it would use the square's one.  
So whatever the last thing it   
was set to, that's what it'll   
use. Question?                  
>> [INAUDIBLE]                  
have to take it up here,        
doesn't have to be              
mutating actually?              
Are you allowed to just         
drop that whenever valid-       
>> Great question,              
he's saying up here look in     
Car, move to, no mutating.      
See, down here in Shape,        
we've got mutating. Up here,    
we've got no mutating,          
that's because Car is a class.  
Class is a reference site,      
they don't need mutating, so    
it's perfectly fine. Any other  
questions about this? Okay,     
excellent. So now let's talk    
about the uses of protocol.     
Now we kinda know what          
protocols are and               
how we can put them in our      
API, how do we use it? Well,    
of super important to use is    
this MVC delegation thing,      
right? We've got these          
generic view things,            
like scroll views and table     
views and things like that.     
And then we've got these very   
specific controller things,     
how does a generic thing talk   
to a specific thing without     
knowing anything about          
that specific thing?            
Because obviously, when scroll  
view shifts from Apple,         
it knows nothing about          
Concentration games. So         
how do we do that?              
Well, we use protocols, okay,   
so like simple, so this is      
the will, did, shoulds and      
So let's take a look how        
we do this, all right? So       
the data at.                    
kinda six steps. First a view,  
like a scroll view or           
table view, it declares         
it's delegation protocol.       
That's just a protocol with a   
list of all the well, dids and  
shoulds that it wants to send.  
Remember protocols just a list  
of methods, right? So           
it creates that protocol. Then  
the view, the scroll view,      
it creates a var in itself,     
a public var, it's weak,        
turns out. And so               
it's an optional and that is    
of type that protocol. Okay,    
now that's great because now    
the view whenever it wants      
to send will, did, should,      
it just sends it to that var.   
And that works because that     
var is of type that protocol,   
so of course it can             
understand all the will, did,   
should. Then the controller     
comes along says, raises its    
hand and says, I implement      
that scroll view delegate       
protocol by putting it on this  
little class line right there.  
And the controller sets         
itself as that delegate var,    
it literally says that          
delegate var equals self.       
So it's setting itself as       
the delegate and that's legal.  
Because the controller          
has claimed, hey,               
I implement that delegate and   
so, and that delegate is of     
type that protocol,             
all is good, okay. And then,    
of course, the controller has   
to implement all the methods    
in the protocol. But            
since this is an Objective-C    
protocol, it actually only has  
to implement the none optional  
ones. Okay and                  
actually in delegation in iOS,  
almost all the methods          
are optional. So usually,       
you only have to implement      
the one you really want. But    
the controller implements       
the methods so they did         
successfully fills out its      
claim to have implemented it.   
And that's it. Now the view is  
hooked up to the controller.    
The view can send will, did,    
and should all it wants.        
It has no idea what kind        
of class is doing it.           
All it knows about, it doesn't  
even know if it's a class,      
could be a struct,              
it knows nothing about it.      
All it knows is that that       
thing implements its protocol,  
so it knows that it can         
send well, did, and             
should to it through            
that delegate var. Okay,        
make sense? So                  
let's look at the code for      
this with the example of        
a scroll view, okay. Oh, yeah,  
sorry. Yeah, you find this      
delegation everywhere in iOS,   
it was designed in Objective-C  
world. In Swift, we have        
closure, which I'm gonna talk   
about later in this lecture.    
And you could use closures for  
some of this stuff. But         
even with closures, delegation  
is pretty cool way to do this,  
have this blind communication.  
All right, so                   
let's look at the example of    
UIScrollView. So this is what   
the var that the scroll         
view would have in itself.      
Okay, this is a scroll          
view var. It's a weak,          
why is it weak, by the way?     
Because here the view           
is gonna have a pointers        
to the controller, and          
we know that the controller     
has a lot of pointers to        
the view. They'd be keeping     
themselves in the heap. Okay,   
so what this view is saying     
here is, I wanna point to       
whoever receives my will, did,  
and shoulds. But if that will,  
did, and should guy             
wants to leave the heap,        
that's fine by me,              
just set this to nil and        
I'll stop sending messages      
to it. Okay, so that way,       
the view won't keep             
the controller in the heat.     
So anyway, notice this is       
optional because it's weak.     
This is the delegate, it's of   
type UIScrollview delegate.     
This is what that               
protocol looks like,            
it's an Objective-C protocol.   
It's called UIScrollDelegate,   
and it's got all                
those funcs in there.           
ScrollView did scroll to here.  
Give me the view for            
zooming over here. It's got     
about 15 of them in there,      
if you go look at               
the documentation. So           
now the controller comes        
along, MyViewController,        
and it puts comma, UIViewCont,  
UIScrollViewDelegate on         
the end and claiming I          
implement that protocol.        
Then, in its probably           
in its outlet setter,           
we'll see an example of this    
today. When that scrollView     
gets hooked up on iOS,          
in the didSet of that,          
it probably says,               
scrollView.delegate = self.     
This is a legal statement to    
say because delegate, which is  
this thing up here, is of type  
UIScrollViewDelegate. And       
MyViewController says over      
here that it implemented that.  
So it's legal for it to set     
itself as the delegate. Okay,   
and once it does this,          
they are hooked up, and         
now the view can send will,     
did, said to the controller     
all at once. Okay, so           
that's delegation,              
probably one of the most        
obvious uses of protocols.      
What's another one? Okay,       
remember, I talked about that   
key in the dictionary in        
the hashable business, right?   
So of course, the key in the    
dictionary has to be hashable.  
How do we enforce this          
in our API? Well,               
there is a protocol             
called Hashable.                
It inherits from another        
protocol called Equatable, and  
that's because you know         
anything about Hashtables.      
When you hash something, it's   
likely to be a unique hash but  
it's not gonna guaranteed.      
You have to follow it up by     
actually using equals to see    
if the two things are actually  
equal, so we hash in works.     
So that's why Hashable          
inherits from Equatable.        
So if you wanna be Hashable,    
you also have to be able to     
check if you're equal to        
something else. Now this is of  
super simple protocol,          
it only has one var in it.      
It's a get only var,            
which is the hash value.        
Some integer, that hopefully,   
uniquely represents you,        
that's what this is. Now,       
let's look at Equatable, okay,  
which, cuz that's another       
protocol that is inherited and  
thus, required here.            
What does that look like?       
That's a very simple            
protocol as well.               
It has one function in it,      
one method,                     
which is static. Meaning it's   
on the type, like get unique    
identifier was in card,         
remember that? And its name is  
==. In Swift, remember, names   
of methods can be like emoji.   
It's not required to be         
alpha numeric characters, so    
they chooses to be called ==,   
which is kind of cool. And      
the arguments are a left-hand   
side and a right-hand side,     
notice that the type itself,    
this is a type method, so self  
is the type. So if this were    
implemented by int, if int      
were implementing equitable,    
self would be int. Okay,        
cuz it would be a type          
function on int, and so         
the left-hand side and          
the right-hand side would       
be ints of course. So           
this is basically saying, that  
your type has to have an ==     
method that compares to ints,   
or whatever you are. And sees   
if they're equal, and returns   
a bool, yes or no. Okay, now,   
this is, that's so that's what  
you have to do to be Hashable.  
But what's really cool,         
that the == operator in Swift,  
okay, when you say like x ==    
y, that's actually not like     
built into Swift or anything.   
All that does is look for       
this method, okay.              
So any two, any class can use,  
can do == as long as you        
implements this protocol. So    
this protocol is required to    
make the Hashable work, but     
it also makes the == operator   
work. And we're gonna see this  
in our concentration demo when  
I go to implement this. So,     
now that we know that Hashable  
means you can be a key          
in a dictionary,                
how is this expressed? Well,    
dictionary which is a generic   
type, right? It's got these     
two types, the type of the key  
and the type of the value.      
It declares itself as           
Dictionary<Key: Hashable,       
Value>, and that means that     
key can only work there if      
it's Hashable. So this is how   
we use protocols to constrain   
these generic types, right?     
Now Value, right there          
in the dictionary, it doesn't   
have any colon anything, so     
Value could be any type.        
You can put any type            
whatsoever as the value         
in a dictionary. But the key    
has to implement hashable. So   
let's go into concentration     
and do this very thing.         
What do we have in a            
dictionary? Well, we have one   
dictionary, it's that emoji     
thing. It's, keys are int,      
ints are hashable so            
we're good, and the values      
are the emoji. And the int      
is our cards identifier.        
Remember that card identifier?  
So, I don't want to do that.    
I want my keys in my emoji      
dictionary to be cards.         
I want to look up               
the cards directly,             
I don't want any of that        
looking at the int thing,       
that's ridiculous. So, if I go  
over here to view controller.   
Here it is right here,          
actually.                       
See, here is my emoji thing,    
int to string, int keys,        
string values, this has to be   
hashable, it is right now.      
But I don't want that,          
i just want to look up          
the cards directly.             
I don't want to use             
the identifier,                 
I am just going to take this    
identifier right off of here    
and when I do this,             
I'm gonna get errors.           
And why am I gonna get errors?  
Because card, see right here?   
Let's see if we can make        
this a little wider so          
you can see it a little         
better down here.               
It says right here that         
we cannot substitute,           
oh, sorry. Okay, it says        
cannot subscript a value of     
int string with a card.         
Of course okay,                 
I said that the keys were int,  
and here I'm trying to do it    
by card. So                     
I'm just gonna say okay,        
that I'm gonna have them be     
cards instead. So I'm just      
gonna have my dictionary, have  
keys of card,values of string.  
So now, what do we got here?    
It says type card               
does not conform to protocol    
hashable, it worked, okay.      
I tried to make a card be       
the key of my dictionary and    
it says, no, card does not      
conform the protocol hashable.  
So the declaration dictionary   
which you can go look up in     
the documentation,              
it says card, the key has to    
be hashable and it wasn't. So   
let's go make card              
be hashable, so                 
we won't have this              
error any more, so              
I'm gonna go over to card,      
here it is. And here is card,   
I'm just gonna say,             
okay, card is hashable.         
So I just made card hashable,   
now of course Swift is gonna    
look at this and say whoa wait  
a second errors here, card      
does not conform to hashable.   
Card does not conform           
to equatable which it doesn't   
because I don't implement       
those methods the hash value    
or the equals equal thing.      
What's really cool in Swift,    
look at the fix button here.    
Do you wanna add protocol       
stubs? Oh, yes please. And      
look what it did. It added      
a stub for hashable, and        
a stub for equitables. Now I    
just have to implement these.   
So, making hash value,          
which has to be get only,       
that's easy. I'm just gonna     
return my identifier. That's    
an extremely good hash for      
a card because it's unique for  
that card. And the equals,      
equals is also really easy      
too. I just have to             
compare these two cards.        
I'm gonna return if the left    
hand side's identifier          
equals the right hand side's    
identifier. So there we go.     
I've implemented hashable and   
equatable. So                   
now if I go back to             
my view controller,             
will that error be gone?        
Here's the error over here.     
So let's make Xcode recompile,  
and sure enough look,           
no problems. It's completely    
fine with that, okay, and       
that's because I made           
this hashable. Now,             
we can get another              
benefit of this.                
Let me go back to card. And I   
told you before, I didn't like  
that this identifier was        
public. I see no reason for     
it to be public.                
And we know we don't need it    
now to look in our emoji        
thing, so I'm just gonna make   
it private. And let's see       
if that's gonna work.           
So is private gonna work?       
Let's build and see. Oh, no,    
we have some errors over here.  
So let's go look at them.       
Here's an error here, it says,  
identifier is inaccessible due  
to private protection level.    
That's right,                   
I made identifier private.      
What's it trying to do here?    
Oh, here I'm trying to see if   
two cards match, oh, well       
cards implement equatable now.  
So I can just go like           
this card matchIndex            
=cards[index] because I can     
compare cards directly,         
now. They implement equatable,  
right?                          
Now if we build,                
that's gone away. So            
we had a huge benefit by        
making that equatable and       
hashable. We got to use it      
directly in our emoji thing to  
make that code look nice and    
look how nice this code looks.  
Compared to how it used to      
look with that identifier,      
right, so we cleaned up our     
code on the use side and        
we were able to go              
back to card and                
make something that really      
didn't need to be public,       
completely private.             
Pretty cool with that? Okay,    
so you're starting to see the   
power of protocols a building   
here. So let's go back and      
look at even more protocol      
stuff that's cool.              
All right, there                
is the demo, okay, let's talk   
a little about this multiple    
inheritance kind of trick.      
Consider countable range,       
remember countable range zero   
dot dot less than something     
creates this countable range    
of ints from zero that thing    
minus one. Countable range      
implements a lot of protocols.  
If you go look at countable     
range, it may have 12 or        
15 different protocols. Well,   
two of the most interesting     
ones it implements              
are sequence.                   
right? A countable range is a   
sequence of numbers from zero   
Which makes sense,              
to something else.              
And also collection,            
because accountable range is    
also a collection of things.    
If it's accountable             
range of int,                   
it's a collection of int or     
whatever. And                   
so these two protocols define   
a lot of fun things like        
sequence defines really         
only one method,                
next, which goes to the next    
thing in the sequence.          
But that let you do for in,     
anything that implements        
the sequence protocol could     
do for in, okay, just like      
anything that's hashable can    
be a key in the dictionary.     
And then, collection            
has even more methods,          
all the indexing, sub-scripts,  
all that stuff is all           
in the collection protocol.     
Now, why do we do this?         
Why do we have countable range  
implement all these protocols?  
Well, because array implements  
all those as well, and so       
does dictionary and set and     
string. All these classes       
that are sequences of things    
or collections of things        
implement all these             
exact same things. And          
so I as a programmer only have  
to learn these things once.     
Okay, I only have to learn      
learn for in once. And          
all I need to know is that      
the thing I wanna for           
in over has to be a sequence.   
So I can just look to see does  
this thing implement            
that protocol? Or               
I can even invent my own        
things that I can for in over.  
All I have to do is implement   
the sequencing, the sequence    
protocol which really only has  
one method in it ultimately.    
So that's one good reason why   
because I learned indexing,     
indexOf to get things and       
I can now do indexOf            
on a string and find            
a character on a string or      
I can do indexOf in             
an array and find in there.     
I can even do indexOf on        
accountable range not super     
valuable but if the count       
of a range wasn't of int,       
then it might be interesting    
to do index of to try and       
find something where it is      
in the range, okay. But         
there's a bigger and            
better reason why we do this.   
And that's because there's a    
little bit of magic in, or not  
magic but really good design    
implementation in Swift.        
Which is that for protocols it  
is possible to provide default  
implementations of methods.     
Default implementations         
of methods. So                  
this makes it possible for      
us to implement indexOf for     
all of these classes in         
one place. So that's why,       
again, we think it's like       
multiple inheritance cuz        
they're actually gonna inherit  
implementation. So where do     
you put this implementation?    
Cuz we know protocol is just    
a declaration method with       
no implementation. Well,        
the answer is you put them in   
an extension to your protocol.  
You know how we can have        
extension int? You can also do  
extension protocol.             
And in that extension you can   
implement as many other         
protocol methods as you want.   
Now you're little bit           
restricted there because        
extensions can't                
have any storage.               
We know that, right?            
No vars, so that's certainly    
a restriction. Also in          
the extension, really the only  
method you could use to         
implement it are the methods    
in the protocol or              
in the protocols you inherit.   
So, like collection, happens    
to inherit from sequence so     
a lot of the collection         
methods can be implemented      
using the sequence by just      
going through the whole         
sequence of the collection and  
finding things, or whatever.    
So if you look here, sequence   
has that one important method   
next goes to the next           
thing in the sequence. But      
sequence also has all           
these other methods,            
contains which finds whether    
somethings in the sequence,     
forEach which kind of does      
what for n does. Joined by      
separator, which takes all      
the things in the sequence,     
converts it to a string and     
creates a big string            
joined by a separator like      
comma or space. It has min,     
find me the minimum thing       
in this sequence, max,          
the maximum thing. Even has     
functions that take closures,   
which I'm going to talk         
about soon like filter and      
map, that do major              
operations on the sequence.     
Well, all the implementation    
of all those things contains,   
forEach, joined, min,           
max all those things.           
Those are all implemented in    
an extension to sequence that   
Apple provides so that if       
you want to have a sequence,    
as long as you implement that   
next thing to go to the next    
thing in the sequence you get   
implementations of all those    
other things for free. That     
also means that array, and set  
and dictionary, and countable   
range are all sharing           
the implementations of min and  
max and all these things.       
Now, these are only             
default implementations.        
If an array you actually        
implement min or max or         
something like that. Maybe you  
can do it more efficiently      
than the default                
implementation or               
whatever. You can do it.        
But it's replace the default    
implementation that's           
in the extension.               
Okay, but are you getting       
the feel for what I'm saying?   
Why this is valuable to have    
these default imitations.       
You can have these really       
powerful protocols and          
you'll only have to implement   
one of the methods and          
you'll get implementations for  
all of them. And then they're   
shared across all these weird   
different classes like array,   
string,                         
countable range. They all get   
all these implementations they  
don't have to implement any of  
that and they get it for free.  
Now all of these that I'm       
talking about generics,         
value typing,                   
var versus let immutability     
control, constraining things    
by protocols, extensions or     
protocols. All these things     
add up to support a kind of     
programming called functional   
programming. How many people    
here have heard about           
functional programming?         
About half of you, see? So      
I encourage you at              
your Stanford careers,          
go take a class and learn       
about functional programming.   
It's really kind of             
the evolution, some would say,  
of object-oriented              
programming. It's a little      
different way of thinking       
about dividing things up.       
It allows you to get things     
like multiple inheritance       
without things getting          
completely out of control.      
Since things aren't             
living in the heap,             
you don't have 20 pointers to   
something and you're not sure   
who's gonna modify things, so   
your programs are much more     
provable,right? You can prove   
that they do what they do.      
You don't have to worry about   
what pointers are messing this  
thing up in the heap lot        
of advantages of it. Now,       
what's really                   
cool about Swift,               
it supports both these          
programming models.             
Object oriented programming,    
which is all I'm gonna          
use in this class because       
that's the prerequisite for     
this class, and                 
functional programming,         
which is what pretty much       
all of the foundation of        
foundation framework like       
dictionary, array, string,      
all those things. Those are     
all built with a functional     
programming model. Swift        
supports them both equally,     
which is really great.          
So it's kind of your best,      
it's a mix between              
languages like Haskell,         
how many of you have ever       
heard of the language Haskell?  
Okay, same people who know      
about functional programming,   
right, so Haskell which is a    
purely functional programming   
language, and you know, like    
Java which is a purely object   
oriented language. It's a good  
mix of two. That's all I'm      
going to say about functional   
programming, just so            
that you know it's there.       
That's it for protocols.        
When you see it all in action   
it will make a lot more sense.  
Hopefully it makes              
a lot of sense.                 
Now it's really,                
protocols are very simple.      
Just those lists but we can     
use them in powerful ways,      
all right. Now let's go talk    
for briefly about something     
that's not super important,     
but strings are in almost       
every app. And I just wanna     
talk a little bit about how we  
index in to strings,            
cuz it is not what you would    
think it is at first glance.    
In addition to string,          
the struct string, there's      
another struct in foundation    
called character. Now,          
a character is what we humans   
would perceive of as            
a character. On the screen or   
whatever. However, a string is  
not a sequence. A string is     
an underlying built with        
character, it's built with      
unicodes. Okay, unicodes are    
just little bite size chunks    
that can represent pretty much  
any language on earth. Okay,    
it's international.             
You know, like ASCII.           
We used to have ASCII, you      
can only really do English.     
Unicodes do all All             
the languages on Earth.         
So that's what's in a string.   
So we have a little bit         
of trying to bridge the world   
between Unicodes and            
characters. So let me           
show you by example here,       
if we have the word cafe,       
C-A-F-E, right?                 
That we perceive to have four   
characters, the C, the A,       
the F, and the E with           
the accent on it. But           
it might be represented by      
five Unicodes, because there's  
a Unicode which is put          
an accent on the previous       
character, okay, so, it could   
have five Unicodes. Well, So    
how do we deal with this?       
Well, the main problem or       
the main ramification           
of this is that string          
cannot indexed by int.          
Because if we had a phrase,     
cafe pesto, right there. One    
of my favorite pizza joints in  
Hawaii, Cafe Pesto.             
The p is that in index 5 or     
is that in index 6? It          
depends on whether that e is    
an e with an accent or two      
Unicode here there's the e and  
the accent. So ugh,             
what are we gonna do here? So   
what we do is we don't          
index strings by int.           
Instead strings are indexed     
by their own special type,      
String.Index.                   
And that's the only way         
to use subscripting             
on a String,                    
you need a String.Index, not    
an Int. So this makes this,     
people don't like this. They    
wanna index Strings by Int and  
I understand why, but           
you can't do that. So           
what does that mean? Well,      
we have to get an index, so     
how do we get an index? Well,   
you can get the startIndex      
of a string, you can get        
the endIndex of a string.       
You can also use index(of:)     
a character to find the first   
index of that character. So     
there's a bunch of different    
methods and vars on             
strings to get an index.        
Once you have an index in       
your hand, now you can offset   
that index by an Int. So        
if you want to get the fourth   
character in the string you     
have to get the startIndex and  
then offset it by three to      
get to the fourth index, from   
the first to the fourth. So it  
was let's get to the code that  
makes that work. So here's my   
pizzaJoint cafe pesto here,     
I'm gonna get the index of      
the first character by saying   
pizzaJoint.startIndex that's    
not an Int.                     
It's of type String.Index.      
Now I'm gonna get the fourth    
character by taking             
the first character and         
offsetting it by three.         
Now I've got the index          
of the fourth character.        
Now I'm gonna get the actual    
fourth character by using       
subscripting. PizzaJoint,       
subscript, fourth character,    
index, fourth character index   
of subtype String.index,        
not of type int. And            
I can also do index (of:), so   
here I'm gonna say              
The firstSpace character in     
cafe pesto is                   
pizzaJoint.index(of: " ").      
Now the reason I have           
to say if let there is,         
of course, index(of: "          
") could return nil.            
There might not be any          
spaces in pizzaJoint.           
There happens to be but         
there might not be.             
So it would return nil then.    
And so I'm doing if let Now,    
I've got the index              
of that space.                  
Now I'm going to get the index  
to the start of the second      
word, the word pesto there.     
And                             
we do it by indexing that       
first space over by one.        
And I am gonna assume there is  
one space in between words,     
go to the next one. And now, I  
am going to get the whole word  
pesto by indexing string with   
a range, okay. The index        
of a string doesn't have        
to be an individual index.      
It could be a range of          
indexes. Now you notice to      
make a range, I'm using         
exactly the same dot,           
dot, less than thing that I     
did when I made that countable  
range of INTs. Ranges are       
generic types. They don't have  
to be of INTs. They can be      
a range of string.index.        
Perfectly legal. As though we   
saw before, we had a range,     
countable range, of double      
precision floating points.      
Remember that at the beginning  
of the last lecture? So         
range is generic type. So       
it is perfectly legal to use a  
range inside subscripting, and  
that's true anywhere there's    
subscripting of collections.    
These methods,                  
by the way, these index,        
offsetBy, those are not         
methods in string,              
those are methods in            
collection. Okay,               
the selection protocol,         
string may or                   
may not implement it itself,    
it's up to the string.          
The collection protocol is      
also generic, and so the index  
you use in the collection       
is configurable. For            
a string it's a string.index.   
By the way, another way         
to get the second word, and     
probably what we would use, is  
a more complicated method like  
component separated by. So      
components separated by, is a   
collection method. You give it  
an element that would be        
in that collection and          
it will create an array         
with all the things,            
all the elements in             
an array grouped and            
separated by that thing. So     
this would give you an array    
of all the words separated by   
a space. Then I would grab      
index one, which would be       
the second word. Okay,          
so I'm showing you how to do    
the indexing directly, but      
a lot of times we use           
much higher level               
things in string.               
Okay, so string,                
like I say, is a collection of  
character. Just like an array   
is a collection of              
arbitrary things,               
accountable range of int is     
a collection of ints, and so    
all that stuff is coming from   
collection. And collection is   
a sequence we know, so          
of course you can do for        
c and if s is a string c will   
be a tight character and you    
can iterate with a four loop    
through all the characters.     
There's also really cool        
initializer for array           
that takes a sequence, as       
the argument. So you can say,   
array of any sequence and what  
it will do is go through that   
sequence and take each element  
and put it into the array.      
So it creates a big array for   
you,                            
cuz it's an array initializer.  
And                             
in the array will be all the    
elements of the sequence. So    
since a string is a sequence    
of characters, if you say       
array of string, you'll get an  
array of its characters. And    
now you can use int to index    
them if you want. So sometimes  
people, they get tired of       
all this string index stuff.    
They just create an array       
of the characters. And          
then now they can use ints to   
get at the various characters.  
That's kind of                  
a trick as well.                
Ah, remember that a string is   
a value type, it's a struct,    
we almost always use immutable  
strings like let s equal        
something, we're working        
with it immutably,              
but of course there             
are mutable versions, mutable   
methods. There's another kind   
of protocol called range        
replaceable collection. That's  
kind of a collections that      
can be mutated. Ranges of the   
things can be replaced. And so  
here's a method in that         
insert the contents of          
a collection of characters,     
which string is, at an index,   
so in this case it's            
index of space,                 
that's gotta be                 
a string.index right there.     
And so I can insert the word    
foo into Cafe Pastel. So        
you can do this,                
we don't do this that much.     
We tend to just use them        
immutably, and we use plus to   
add them together and stuff     
like that. So that's string,    
it's that little weirdness      
about the indexing.             
Now, There are lots of other    
methods in string, I want to    
show you an interesting         
thing about one of them.        
So here is replace range,       
which, my pointer doesn't work  
any more, but                   
if you look at replace range,   
do you see where it's red,      
right there? That's that dot,   
dot less than thing, look,      
I forgot to put something on    
the left. So what does          
that range go from? Okay,       
we know it goes to s.endIndex.  
Well, Swift is smart enough to  
know that that is a range of    
str-, the strings indexes,      
so it will automatically put    
start index at the beginning.   
And if you left off             
the other side,                 
it will automatically put       
ending index at the end. So     
you can oh, leave those         
arranged things open ended.     
But Swift has to be able to     
infer the type of whats going   
on there. So                    
you can't always do it,         
but in that case you could.     
Okay, so                        
that's string. I guess          
we'll go like this. So, to      
make this all understandable    
let's go back to our,           
um, concentration.              
And we're gonna make this       
thing right here,               
this emoji choices,             
which is currently              
an array of emoji strings.      
I'm gonna change that. I'm      
gonna copy and paste it here.   
I'm gonna change it from being  
an array, to being a string.    
So I'm gonna take off           
the array things.               
And I'm gonna get rid of all    
of these little commas. And     
now emojiChoices is             
gonna be a string.              
And I'm gonna have              
my code be the same,            
but instead of grab it out of   
the array, it's gonna grab it   
out of the string. Now as soon  
as I change that to a string,   
look what happens.              
Cannot convert value of type    
int to expected argument,       
string.index. Okay, remove at,  
right here, which we moved      
to remove the thing,            
where do you think that's       
declared? Anyone wanna guess?   
Is that an array thing?         
A string? No,                   
that's in collection, range     
replaceable collection, right?  
So it's in a protocol           
somewhere that both string and  
array implement. So             
you would think it              
should just work here,          
because emoji choices, yeah,    
now it's a string, but remove   
at is in range replaceable      
collection, they're range       
replaceable collection.         
Why does this work? Well,       
because strings are not         
indexed by ints. And            
so this doesn't work. So we     
have to create a string.index,  
I'm gonna do that. I'm gonna    
create a random string index    
and I'm gonna do it by using    
that index offset by things.    
I'm gonna say, emojiChoices     
give me an index, I'm gonna     
use this first one right here,  
index offsetBy, which let's us  
take a known index and          
offset it by something else.    
The known index I'm going to    
start with is the start index   
of this thing, so,              
emojiChoices.startIndex, and    
I'm gonna offset by a random    
int. So that offset,            
that can be by an int.          
That happens to be because      
this particular collections     
strides, or the distance        
between indexes is an int.      
Even though the indexes         
themselves are string           
dot index. So I do that.        
So now I'm gonna put random     
string index in here and        
all should be well, right?      
Because remove at,              
oh no, still doesn't work.      
What's this error?              
Cannot assign value of          
type character to string.       
Okay, this is a dictionary,     
this is looking for             
strings. Okay?                  
Why is this a character? Well,  
because a string is             
a collection of character. So   
if remove at, I'm removing a    
character. So no problem here,  
we know that we can             
probably convert types. And     
we're gonna do that by using    
a string initializer that       
takes a character               
as an argument and              
returns a string with just      
that character in it. So now    
we converted it. So, that's     
it. That's all we need to do.   
And I did this just so you can  
see all that offsetBy, and      
all that stuff so you could     
see how we would index this     
into a string instead of        
doing here. So, hopefully       
this is still working. Yes,     
it is. It's still working.      
Okay? Got it everybody?         
Questions about this? So        
this is the important line      
of coding in here. And          
also a little bit of            
understanding that even though  
remove at is in collection      
range, replaceable collection,  
the types matter,               
because it's a generic type.    
Collection is a generically     
typed protocol. All right,      
let's go back. Oops,            
not there. Here, no. Here.      
All right, let's talk about     
another class that has          
to do with Strings which        
is NSAttributedString. For      
NSAttributedString is           
a String that every character   
has a little dictionary         
associated with it. And         
that Dictionary can have        
lots of little keys and         
values that say how to draw     
that character on screen.       
Okay so those Dictionaries can  
have things like font, color,   
all these things. Okay that's   
what an attributed string is,   
right? A String with            
attributes of each character,   
right? The Dictionary that      
each character can have.        
The keys are well known,        
you can look them up            
in the documentation.           
The values depend on            
the type of thing, so           
sometimes the values are UI     
font, which is a font thing,    
sometimes the values            
are colors,                     
sometimes they're floating      
point numbers, etcetera.        
Now a lot of times, we use the  
same Dictionary for big long    
ranges of characters, right?    
You know like if users select   
some text on screen and they    
say make it orange, then we're  
gonna have one Dictionary for   
all those characters so not     
like every character has to     
have a different Dictionary.    
And in your homework,           
the entire String is going      
to have one Dictionary. So      
I've given you a really easy    
use of attributed String and    
you're gonna see why I did      
that in a moment here.          
Once you have an Attributed     
String with all those font and  
color for each character,       
now you can use to it to set    
the text in UI label, or        
to set the title of             
a UIButton. Or next week we're  
going to learn how to draw it   
directly on-screen, in our own  
drawing classes. Okay?          
Here's how you create and       
use an AttributedString,        
and it's got red.               
Any time you see red on my      
slides, it's kind of like oh,   
look out. And this is red       
because it's really weird.      
Okay? And why is this really    
weird? Well, it's really weird  
cuz this is an Objective-C API  
that's trying to live           
in the Swift world, and         
that requires a little bit of   
compromise. There's not         
a lot of APIs like this.        
Every time iOS comes out, the   
next one I always hope there    
can have                        
Non NSAttributedString, just    
regular AttributedString would  
now fix this, but they haven't  
done it yet. So, when you're    
declaring those attributes,     
the little Dictionary that      
goes on each character,         
you have to give it             
an explicit type.               
You cannot let the type         
be inferred and                 
that's because those            
values could be font,           
colors, whatever. So, a source  
can't infer what the value of   
the Dictionary is. So they      
type that you're gonna use      
here is Keys                    
are NSAttributedString key.     
And you can just look that      
up in the documentation,        
see what the choices are. It's  
things like font, underline,    
strike through, all the things  
you would think to be.          
And then the value is Any.      
Okay, so                        
Any is a special Swift          
thing that means                
anything can go here, any       
struct, any class, any type.    
So this is very non Swift       
cuz Swift is strongly           
typed, and                      
here's there's no type. So      
you would never have an API     
like this in Swift. Okay,       
if this weren't an Objective-C  
API brought forward, so         
you would never have it.        
Can anyone think of what        
we would have instead of        
any right there? Why type       
of thing instead of any?        
How about an enum with          
associated values? Right?       
If you had an enum, and one of  
the enum things is the font,    
then the associated             
value could be a font.          
Or what if the thing was        
the color of the text?          
Then the associated             
value could                     
be a UI color, you see? How we  
would do that in Swift? Well,   
we didn't have those enums      
when Objective-C did this so,   
we're stuck with Any. Okay?     
Never use any in your data      
structures. Any is purely so    
we can deal with these old      
Objective-C things. Alright,    
so, now that I have declared    
the type to be a dictionary     
with NSAttributeString keys     
with Any as the value, then I   
can make my dictionary and      
so StrokeColor is obviously     
the color that it strokes       
the outside of the text.        
There's also foreground color   
which is the color it puts      
the inside of the text,         
the fill color. There's also    
background color which is like  
if you had a highlighter,       
that's the background of it.    
There's also StrokeWidth.       
StrokeWidth, if it's            
a positive number,              
it outlines. Okay? If it's      
a negative number its solid.    
The character is solid. Okay?   
You'll see that. We're going    
to do a demo of that. Okay? So  
you can do this. You can put    
these things in here for your   
homework. You'll use stroke,    
color stroke with maybe a       
couple others. In the hints I   
kind of tell you the things     
you need to use.                
So, I don't want you wasting    
too much time looking up all    
these things. Then you can      
created an attributed string    
with that Dictionary for        
all the cards in the string by  
just saying NSAttributedString  
using the initialize of         
the text of string and the      
attributes. So that creates     
an attributed string then       
I can take that attributed      
string and like put it on       
my flipCountLabel, right?       
Now my flipCountLabel, so       
this particular ones since I'm  
using a positive stroke width   
this would be outlined text.    
On my flip count.               
So I'm gonna do a demo and      
see what that looks             
like in a second here.          
I just briefly want to talk     
about the peculiarities of      
NSAttributed strings            
since there's an NS.            
You know, you see that NS at    
the beginning and you know,     
hmm, this is kinda              
of an older API.                
It's not a String. It's a       
totally different thing, okay.  
An NSAttributedString is        
a class that's completely       
different. Then String worked   
completely differently.         
Because it's a class            
not a struct,                   
you can't make a mutable        
one by just using var.          
You actually have to            
use a different class.          
And it's mutable Attributable   
String. If you actually         
wanted to go set                
the dictionaries on certain     
characters individually, you    
would need to use a mutable     
Attributable String,            
a completely different class    
there. Also NSAttributedString  
was built and                   
constructed internally with     
NSString in mind. NSString is   
the old Objective-C String.     
NSString and String have        
a little different Unicode and  
coding underneath. So,          
when you have wacky characters  
like emoji or cafe in there,    
the indexes into them might     
not quite match up. And         
there's automatic bridging      
between string and NSString so  
if you have any iOS API         
that takes an NSString          
as an argument,                 
you can just pass a string.     
It just automatically           
works except,                   
that this little encoding       
doesn't always get              
fixed up quite right so the     
bottom line here is if you're   
going to be trying to be index  
into an NSAttibutedString and   
you have wacky characters like  
emoji or cafe, the indexes      
might not line up very well.    
Now in your homework you don't  
have to worry about any of      
that cuz I'm only gonna ask     
you to make the entire String   
have the attributes. So         
you're not even doing           
any indexing into there.        
But in the future, if you're    
ever using AttributedString,    
just be careful about           
the indexing in there if        
you've got wacky characters.    
All right, the demo. So,        
I'm gonna do this flip count    
thing and show you what this    
looks like real quick here.     
Where do we do that?            
That's right up here,           
right? Here's where we set      
our flipCountLabel to Flips:    
\(flipCount). So I'm going to   
put attributed text there. So   
I'm going to let my             
attributes, which I have to     
type to be                      
[NSAttributedStringKey:         
Any] =. And now I can just      
put the things I want, so       
I want the StrokeWidth          
to be 5.0.                      
Okay, that's a fairly           
thick stroking width.           
And then what was the other     
thing I said I wanted to, oh,   
the color. So the strokeColor   
and I'll go ahead and           
use the color literal here.     
Use our favorite color,         
which is orange.                
Halloween color. Okay,          
so now if I wanna use these     
attributes to draw the text on  
my label, I'm just gonna        
create an attributedString.     
So I'm gonna say,               
let attributedString equal. By  
creating an attributedString    
with its constructor,           
I want the one down             
here at the bottom.             
It takes attributes and         
string. Okay, so                
what you're gonna do for your   
Homework-2. I put the string,   
it's just this string           
right here. And                 
attributes is these attributes  
I just created up there. And    
then instead of saying          
flipCountLabel.text,            
I say attributedText. And for   
a button, you would say set     
attributedTitle for             
state instead of setTitle for   
state and that equals           
this attributedString.          
Okay, so that's all you need    
to do. So let's run this and    
we're gonna see something       
a little bit kind of odd about  
this, though. A little          
bit unexpected, I think.        
So here we go. Hey, it didn't   
draw anything different.        
Look at that, Flips: 0.         
That looks exactly like         
before we made this change.     
But, oh, look, if I click, now  
I'm getting the outlined font.  
See how it's                    
outlining my Flips?             
So why when it first came up    
didn't this work, right here?   
Yeah because this right here,   
this little =0,                 
this initialization, that       
does not cause the didSet to    
happen. Okay, so that's         
an important thing to know.     
When you initialize a var,      
it does not invoke the didSet,  
only later settings             
of flipCount. So                
how can we fix this?            
Well, I'm gonna take this and   
put it in it's own little       
func. Okay, private func,       
I'm gonna call it               
updateFlipCountLabel.           
I'm gonna put that in there,    
and                             
I'm gonna call this             
updateFlipCountLabel in here.   
updateFlipCountLabel, and       
where's the other place I need  
to update the FlipCountLabel?   
Well, here's another thing to   
learn that's kind of cool.      
This, right here,               
is the label, right?            
If you remember in our UI over  
here, that this right here      
is connected up to that,        
right, it's connected. Now,     
this connection gets made by    
iOS when you start up your UI,  
right, it makes                 
that connection.                
Well, when it makes that        
connection, it's setting this.  
So guess what,                  
we can use didSet here.         
When you have an outlet,        
didSet does get called when     
that outlet gets set by iOS,    
when this connection right      
here gets made, that gets       
called. So here we can update   
our flipCountLabel here. Okay,  
so now that flipCountLabel is   
gonna be updated when we first  
connect that flip zero and      
also every time we change it    
after that. Got it? All right,  
back to our slides. So,         
you learned two things there,   
right? You learned that that    
equal zero didn't cause didSet  
to happen and you learned that  
on an outlet, you can didSet.   
You can set things because      
that outlet just got            
hooked up for you.              
All right, last really, really  
important thing here. We need   
to really rush, because         
we're running out of time.      
This is very important, this    
is about functions as types.    
So I believe the supreme court  
a couple of years ago that      
functions are people too.       
And so functions get the full   
treatment of a type that        
any other type gets.            
You can use a function as a     
type anywhere, all right? And   
you do it just by declaring     
an argument to a function or    
a var, whatever,                
to be of type function.         
And you specify                 
the arguments and               
the return value of             
that function. So               
it'll be a variable of that.    
So you can do this anywhere     
a type is allowed. Let's look   
at an example. I have a var     
here called operation. It is    
of type function that takes     
a double and returns a double.  
So the syntax here is awesome.  
It looks just like declaring    
a function that takes a double  
and return it, just no names    
of arguments, but the types     
are all in there. So this is    
how you declare a function.     
You declare a var               
that is a function.             
You can do it for variables,    
passing to functions,           
parameters, everything.         
You can always do this. So      
you can assign this var, it's   
exactly like you would think.   
I'm gonna assign                
operation = sqrt. Okay,         
sqrt is a function that takes   
a double and returns a double.  
So it's perfectly legal for     
me to say operation = sqrt,     
all right? And how do I call    
it? Well, I call it just like   
a function. Operation of 4.0    
is gonna call, in this case,    
square root of 4.0, because     
operation is a function var,    
that's holding a functioning.   
That function is square root,   
okay. Could not be simpler.     
Everybody cool with this? Now,  
other languages have function   
pointers and all this stuff,    
but it's all pretty tortuous    
to use. But in Swift, it's      
a first class citizen, okay.    
Functions are a first           
class citizen.                  
They will be the argument       
to many iOS methods,            
functions will be.              
Okay, now a lot of times,       
the function you wanna past     
doesn't already exist.          
So forces you to go write       
a function to pass in. For      
example, let's say I had the    
function changeSign, okay. So   
there's no thing like square    
root that does change signs.    
So I have to write a really     
simple little function here,    
And all it does, it takes       
a double and returns a double,  
changeSign.                     
just like square root. And      
it returns minus the operand.   
So I'm changing the sign of     
the operand here. So I could    
use it in the same way. I've    
got an operation. I'll just     
say operation = changeSign      
instead of operation = sqrt.    
But this is kind of             
a lot of typing and             
annoyance to have to go         
create a whole function to do   
changeSign when all I want is   
for that thing to change sign.  
So we can do,                   
use what's called a closure.    
How many people have            
heard the phrase closure,       
know what a closure is?         
Okay, about half of you again.  
Okay, so closure is really      
like an inlined function. It's  
a little special in that it     
captures the state around it    
but it's essentially an inline  
function. So what does the      
syntax look like if we wanted   
to take changeSign and just     
drop it right into the middle   
here instead of having          
a separate function? Okay,      
how would we do that?           
All right,                      
we're just gonna pick up all    
of changeSign except for        
its name and move it down.      
Watch, okay, so I just put      
it right in there. Now I        
do have to make one syntactic   
change here, very important.    
I have to move that first       
curly brace, the one right      
before the word return. I had   
to move it to beginning and     
replace it with the word in,    
so watch this happen.           
This moves to the front, put    
the word in. That's it though.  
Once you make that small        
syntactic change, you can drop  
any function right in there.    
But it gets much better on      
this because we have type       
inference in Swift. And Swift   
can absolutely go to town here  
because it knows a lot about    
what's going on here. For       
example, Swift knows that this  
operation thing returns         
a double. It knows that, so     
you don't need to say returns   
double there, so just take      
that out. it also knows that    
the operand is a double, so     
you don't need to say that      
that operand is a double,       
you can take that out, right?   
It also knows that this         
function returns something, so  
you don't need the keyword      
return minus operand there. So  
we can take that out as well.   
Okay, and even more,            
Swift knows you want to have    
these embedded functions all    
the time, and it's a little     
annoying to have to think up    
a name for the argument         
to this thing. Okay, that       
operand word that I had to      
think up there. So it lets you  
substitute $0 for the first     
one, $1 for the second, $3 for  
the third one. So I'm gonna     
replace operand there with $0.  
And when I do that, I don't     
need the in anymore either.     
Now you see the power           
of the closure. Okay,           
I wanted to have an operation   
that changes the sign.          
And I barely had to type        
any more characters than        
the changeSign, just the curly  
braces around it. And that's    
still gonna do, operation 4.0   
is still gonna do -4.0. Okay,   
so you're gonna be using        
closures all the time, and      
you're gonna be using           
these $0, 1, $1, $2,            
as the argument names. And      
it's gonna make it so that you  
have to type very little        
code to put the things in.      
Now why do I want closures,     
why do I want functions as      
arguments? Well,                
it's usually because you,       
you're passing something to     
a function that wants to know   
what to do. A function is       
a great way to tell it what to  
do. Now why might it want       
to know what to do? Well,       
maybe it wants to know what     
to do if there's an error.      
I'm gonna do something, it      
might generate an error, and    
I want to call a function       
in case there's an error so     
you can handle this function.   
Maybe it wants to know what to  
do if it's gonna do something   
that takes a long time.         
It's gonna go on                
the network and                 
download something off in the   
background and when it's done,  
it wants to tell you. Okay,     
we call a function to do that.  
Another thing is, it might be   
doing something repeatedly,     
it wants to do the same thing   
over and over. So it's asking   
you to tell it what to do over  
and over. So let's take a look  
at an example of that last one  
there, doing something over     
and over. So array,             
naturally, it's a collection.   
Well anyway, array has          
a method called map. And        
what map does, it takes only    
one argument, a function. And   
it applies that function to     
every element in the array and  
creates a new array. So         
map returns a new array where   
every element in the array you  
send it to gets operated        
on by some function.            
In other words, it's a way to   
pass a function into array and  
tell it to do it on             
every element. Okay,            
that's what map does, so how    
does that work? Here I have     
an array of floating point      
numbers. They happen to be      
the first 5 prime numbers,      
right, 2, 3, 5, 7, 11 here.     
And what if I wanted to have    
an array of all negative 2,     
negative 3? Well I would        
just say negativePrimes =       
prime.map, the only argument    
is a function that does change  
sign, right? Just like we       
had on the previous slide,      
change sign. And                
now we're getting a new array,  
negativePrimes is gonna be      
a new array with -2, -3, -5.    
You see how I used map there?   
Now, list another example,      
maybe inverting the primes.     
So I'm gonna propriate          
the closure, 1.0 divided        
by $0. Now I get 0.5, 0.33,     
maybe I even want to            
convert it to a string.         
Perfectly legal, doesn't        
have to be the same type.       
I can return array of string.   
Now notice the yellow           
things up there, changed a      
little with each line. You see  
the first one map parentheses   
the closure. The next one       
map open parentheses, closed    
parentheses then the closure.   
And the third one map, no       
parentheses and the closure.    
Okay, this is using what's      
called trailing closure         
syntax, okay, we almost always  
use this. The rule here is,     
if the last argument to         
any function is a closure,      
you can move the closure        
outside the parenthesis of      
the arguments. So see in the    
second line, inverted primes?   
How I moved the closure         
outside? And furthermore,       
if it's the only argument,      
then you can just get rid of    
the parentheses entirely.       
That's the third line, okay.    
And this is just to make our    
code look nice. So we don't     
have extraneous parenthesis in  
there that we don't, beccause   
we've got the curly braces,     
we kind of don't need           
those parentheses. Okay,        
so you'll see that in iOS when  
an argument to a function       
is a function, it'll usually    
be the last argument. So        
that you can move it            
outside if you want.            
It's optional,                  
you don't have to.              
All three of those are          
perfectly valid syntax right    
there. Okay,                    
another cool use of closures,   
property initialization. What   
if you have a property and      
you wanna initialize            
it to something but             
it's not like you just can't    
do one line thing, right.       
You can't say equals five or    
equals something simple. You    
need to do two or three lines   
of code to get it initialized.  
No problem, you're allowed      
to set the property equal to    
executing a closure. Now that   
closure is automatically        
going to be a closure that      
takes no arguments and          
returns the right type to       
initialize that property.       
So you can do anything you      
want in that closure and        
just return something           
of the right type. And          
then you execute it right away  
with open parenthesis, closed   
parenthesis. See how there's    
the little open parenthesis,    
closed parenthesis there right  
at the end of the closure?      
That's just gonna execute       
that closure right there.       
This is especially cool with    
lazy properties. Because it     
means, this closure won't be    
executed until someone asks     
for this property. Okay, so     
you're combining lazy           
in the closures. So             
closures really cool for        
initializing properties. Now,   
one thing about closures        
to be careful of.               
They do capture their           
surrounding variables.          
So if I have a closure, it's    
just a function embedded right  
in my code. If there            
are local variables, or         
instance variables in the       
class I'm in, or whatever, and  
I use them in the closure       
it works. And even if that      
closure sticks around, those    
things still continue to work   
until the closure goes away.    
What this means, though,        
since closures are types and    
they can put in arrays and      
dictionaries, closures          
are reference types.            
There's only two reference      
types in Swift, classes and     
closures. So                    
what does that mean?            
It means this closure gets put  
in the heap if you put it in    
an array. So that array         
actually has pointers to this   
closure. Now this is a little   
mind bending. I don't expect    
you to get this right at the    
top. But it also means that,    
if you capture variables        
in your closure from your       
surrounding code, they have     
to go live in the heap too.     
Because we can't have this      
closure not function, right?    
Can't if this function has to   
be a function that executes.    
So here's an example of that.   
Here I have a local             
variable called ltaue,          
life the universe and           
everything,                     
I think that stands for.        
It's set to 42. Okay,           
and my operation, the closure   
there, says ltuae times $0. So  
that closure is actually using  
a local variable inside it.     
Now what happens if I put that  
operation in an array? Okay,    
and then later go back and      
get it out of the array, and    
execute it. Well, when it does  
that, ltuae still needs to be   
there. Because otherwise,       
the closure won't execute. So   
ltuau, the ltuae gets           
captured into the heap and      
stays there until               
the closure goes away.          
Now, this is awesome,           
it all just works magically.    
You don't have to think about   
it, except in one case, and     
that's a memory cycle.          
This can create a memory cycle  
because you might capture       
the class that array of         
operations is in. Okay,         
if you capture the class that   
array is of operations in,      
then this closure has captured  
that class into the heap. And   
that class through              
its array is captured           
the closure in the heap. So     
they're pointing to each        
other through the array,        
you see? They're creating a     
memory cycle, that closure is   
keeping the class, the class    
is keeping the closure.         
They're staying in the heap,    
they can never leave until      
someone removes that closure    
from this array,                
for example. So,                
we can break closure cycles     
like these. We use that thing,  
I talked about last time,       
unowned. Remember, unowned?     
When we talked about weak and   
strong and unowned.             
And I said, I'll tell           
you what unowned is. So         
I'm gonna put these two         
things together. Unowned and    
the fact that we can have       
these cycles. In a couple of    
weeks, I'll talk to you, how    
we break these cycles. Okay,    
how we can create a closure     
that will not keep              
something else in. Okay so,     
let's see a demo of closures.   
I'm gonna improve the method    
index of the one and only face  
card to be way better. And not  
only am I gonna use closures,   
I'm gonna go back and use       
extensions to protocols, and    
I'm gonna tie this all          
together. Okay, so              
lets do that.                   
Over here, if we remember,      
our, we'll make it one          
big window here. If we go       
back to our concentration, all  
right, here's concentration.    
Remember we had index of        
one and only face card,         
which, supposedly made          
our code simpler,               
which it did down here.         
It made this code really        
beautiful and readable down     
here. But, it actually added    
quite a bit of code here. But   
this is way more code than you  
actually need To find           
the index of the oneAndOnly     
face card, if you use a method  
that takes a closure. Now,      
the method we're gonna use,     
it's kinda like map,            
its own collection, it's        
called filter. So what filter   
does is it goes through every   
item in the collection and      
executes a function that you    
provide. Filter only has one    
argument. It's a function.      
That function returns a bool.   
So it executes that function    
with the argument being each    
item in the collection.         
If that function returns true,  
then it puts it in              
a new array, okay, and          
if it turns false, it doesn't.  
So essentially                  
filters the collection into an  
array, but only the ones that   
return true from the function.  
See what I'm saying? So         
that's why it's called filter.  
Filters the collection,         
makes an array out of the ones  
that return true. Well,         
that's great for this, because  
index of oneAndOnly face card.  
How about I go look at all      
the indexes of the cards and    
just find the indexes that      
have face up cards? So I just   
need a function that says       
whether a card's face up and    
I can do it. So let's do that.  
I'm gonna let index, we'll say  
the let the face up card        
indices I'll call it, okay,     
this is gonna be an array. I'm  
gonna let it equal to my card   
indices. Card indices,          
what type is card indices,      
anyone remember? Oh I just      
showed you what it was.         
Right, right? It's accountable  
range of int. It indexes into   
the cards array. So I'm gonna   
filter those indices by         
providing a function.           
And it's the only argument, so  
I don't need any                
parentheses or                  
anything, I'm just gonna put    
it after. This function just    
needs to look at the index and  
see if that's a face up card.   
So that's cards sub the index,  
we'll just use $0,              
which is the one argumentative  
function, isFaceup. Okay,       
so that's a Boolean function,   
right here.                     
This is a Boolean function,     
executed by a closure, right    
in there that returns true, if  
the card of that index is face  
up. So, now I've created        
this which is an array,         
it's an array of array          
indexes by the way.             
Let's take a look, see.         
Array of array indexes.         
This type Array.Index,          
remember, we had String.Index,  
Array.Index, is type aliased    
or just set equal to be int.    
That's why arrays can           
be indexed by int,              
cuz their Array.Index is int.   
That's not true for strings.    
String.Index, unfortunately,    
is not int. Okay, so            
this is an array of all the     
indices. Now, if this only has  
one thing in it then we         
have one face up card.          
We all agree with that?         
So I'm just gonna return here,  
that if                         
faceUpCardIndices.count ==1,    
I am going to return            
the faceUpCardIndices.first,    
first is just a collection      
method that returns the first   
thing in the collection.        
Otherwise, I'm gonna return     
nil, because we either          
have zero face up cards or      
we have more than one, in       
either case, we'll return 0.    
So I don't need any of this     
stuff right here. Okay,         
so this is a lot cleaner        
than this whole thing.          
Everybody agree with that? And  
a little more readable too.     
Give me all the face            
card indices by filtering       
the indices to show me the      
ones that are face up. Okay,    
it kind of reads a little       
better as well, but             
we can do better                
than this even.                 
And we're gonna do better       
by creating an extension to     
a protocol down here. The       
protocol we're gonna extend is  
collection. So we're gonna add  
a var. Could be a function,     
but it's gonna be               
a var to collection.            
So, I'm gonna be adding         
it to string, dictionary,       
array, all these things.        
And what it's gonna do,         
it's gonna be the oneAndOnly.   
And it's gonna return           
the one and only thing in that  
collection, if there's only     
one thing in the collection or  
it's gonna return nil.          
Now, what is the type,          
of oneAndOnly gonna be? Well,   
collection is a generic type.   
And it has one of its           
generic things as element,      
which is the type of the thing  
in there. So element is just    
like a placeholder, right,      
in the array of element.        
You recognize that? For in      
a generic type, it's the type.  
And of course I want            
it to be optional.              
Because I'm only gonna return   
non nil, if there's one and     
only one thing in this          
collection, this string, or     
this array, or                  
this dictionary, or             
this countable range.           
And here's how I can implement  
it, watch this. Return count    
== 1? first : nil.              
Now how am I able to do this?   
Well count is a collection      
method, tells how many things   
in there. first is a            
collection method, it returns   
the first thing in there.       
So since these are collection   
methods, I can use them in the  
implementation of a collection  
var. Seeing the power here of   
these extensions on protocols.  
And now, strings, arrays,       
countable ranges,               
they all implement oneAndOnly.  
So I can go back up here and    
just return, Return this,       
remember, it's an array         
of the indices of face up       
cards, dot oneAndOnly.          
Okay, and I don't even need     
this. Okay, even simpler.       
By the way,                     
I could absolutely do, let ch   
= hello.oneAndOnly. Okay,       
now that would return what?     
What would ch be equal          
to there? Anybody?              
>> It would be nil,             
because oneAndOnly returns      
if there's one and only one     
element and this string has     
five elements. If I did this,   
what would this return? This    
will return h, the one and      
only thing in that string.      
So I got that by                
extending collection, which     
string and array happen to be.  
What's the type of this,        
by the way? ch,                 
what do you think its type is?  
It's an optional character.     
Optional character because      
the elements of a string are    
characters. And a string is a   
collection of characters. But   
if I click on it, it's gonna    
say, it's a String.Element.     
So just like Array.Index        
is type alias to be int,        
String.Element is type          
alias to be character.          
So, you have to look in the     
documentation to see that or    
you just have to know it.       
But if you're doing your Alt    
clicking, I don't want you      
to be surprised when you        
see that's not a character.     
Okay, all right, so a lot of    
things went on in just this     
short demo here. We used        
the closure right here. And     
we also extended a protocol     
right here to create this       
method here. So hopefully you   
understand both of those.       
If you don't, use Piazza, come  
up and ask me afterwards or     
whatever. All right,            
see you next time. Oh,          
wait, sorry one thing,          
let me go back and              
just show you the coming up.    
Because there is one thing to   
note here about the coming up.  
Which is that Friday,           
we were gonna have              
the optional section            
object persistence, we're not   
gonna do that this Friday.      
We'll do it in                  
a future Friday,                
we will do object persistence   
but in a future Friday.         
So, there's no Friday section   
at all this week. Next week,    
I will be doing views,          
gestures, multi-touch,          
multiple MVCs, all that.        
>> For more,                    
please visit us                 
at Stanford.edu.                
