[As described below, this is Part C of a 3-part course. Participants should complete Parts A and B first -- Part C "dives right in" and refers often to material from Part A and Part B.] This course is an introduction to the basic concepts of programming languages, with a strong emphasis on functional programming. The course uses the languages ML, Racket, and Ruby as vehicles for teaching the concepts, but the real intent is to teach enough about how any language “fits together” to make you more effective programming in any language -- and in learning new ones. This course is neither particularly theoretical nor just about programming specifics -- it will give you a framework for understanding how to use language constructs effectively and how to design correct and elegant programs. By using different languages, you will learn to think more deeply than in terms of the particular syntax of one language. The emphasis on functional programming is essential for learning how to write robust, reusable, composable, and elegant programs. Indeed, many of the most important ideas in modern languages have their roots in functional programming. Get ready to learn a fresh and beautiful way to look at software and how to have fun building it. The course assumes some prior experience with programming, as described in more detail in the first module of Part A. Part B assumes successful completion of Part A. The course is divided into three Coursera courses: Part A, Part B, and Part C. As explained in more detail in the first module of Part A, the overall course is a substantial amount of challenging material, so the three-part format provides two intermediate milestones and opportunities for a pause before continuing. The three parts are designed to be completed in order and set up to motivate you to continue through to the end of Part C. Week 1 of Part A has a more detailed list of topics for all three parts of the course, but it is expected that most course participants will not (yet!) know what all these topics mean.
Mixins
Loading...
En provenance du cours de University of Washington
Programming Languages, Part C
205 notes
À partir de la leçon
Section 9 and Homework 7 (Second Module With Ruby)
Welcome to the second week of Part C where we will focus on how functional programming and object-oriented programming encourage such "exactly opposite" decompositions of problems that they are "more alike than you might realize". This is a key opportunity to synthesize much of what we have learned so far. As the welcome message discusses in more detail, we will go a bit beyond this to touch on some related advanced topics and then dive into the last -- and challenging -- programming assignment, which involves porting an interpreter from ML to Ruby.
Rencontrer les enseignants
Dan GrossmanProfessor
Computer Science & Engineering
[MUSIC]
In this segment let me show you Ruby's Mixins.
These are a nice alternative to multiple inheritance.
And are very similar to what are called traits in some other
programming languages.
So what is a Mixin?
It is a collection of methods and only a collection of methods, so
it's not a class.
You can't instantiate it.
You can't call new on it to get an instance of a Mixin.
It is just a bunch of method definitions.
Now, what do you do with a Mixin?
Well languages, typically let you,
in a class definition include as many mixins as you want.
You can still have a super class.
You still inherit those methods.
Then you can also include Mixins and you get all of their methods, too.
It is like you typed out the same method definitions.
By including the Mixin, you avoid that copy and paste.
So, it it really is just adding method definitions to
some class when you include the Mixin.
That way, you can extend your class definition with those methods.
You can by including a Mixin override a method that was
typed into a superclass and so on.
So, this is really quite powerful.
And the key reason we're going to see is,
those Mixin methods that you include in your class can use self.
They're so much part of the class definition that they can call
other methods that you define in your class.
That's going to be the key power we see.
So, I'm going to show you a simple example first.
We'll get to the cooler stuff in a bit, so it turns out in Ruby,
we'll use this module keyword to define a Mixin.
Module is also support name space management,
so it's getting two different things.
But here,
I'm just going called them Mixins,because that's what they were using them for.
So, here's a Mixin I'm calling Doubler.
It happens to just have one method to find it.
We could define as many methods as we want and this method is called Double.
And when you call this method,
it send self the plus message with self as an argument.
So in this mixing, we are not defining plus.
We are only defining double.
We are assuming that any class that includes us
will have plus define and we will call the plus method.
So what we could do is, define a class like you see here, Point.
Define the plus message, which just takes the x coordinate and
the y coordinate and adds them together.
Then, by including Doubler, so you just write keyword include and
the Mixin you want to include.
This class now has a double method and
when you call it, that method will call the plus method.
So, I've already loaded everything up over here.
In fact, I've already even defined the point that I just previously created.
And set the x corner to three and y corner to four.
And now, it has a plus method, so I could say p plus.
Well, I guess p is the only point I have, but
I don't have to it that way, it also a double method.
And you see as a result here that x is returning a new point where x is
six and y is eoght.
And of course, that point also has a double method and so on and
this works great.
So, we successfully did it.
Now, you may have seen here over in the code that I also went and added,
the doubler Mixin to the class string.
Now, this is questionable style, going and changing an existing class.
But it does work and indeed, if I come over here and I type "hello".double.
It now has that method.
All its doing is, calling the plus method on strings with hello itself and
since plus concatenates, we get hello hello back.
So you can do this, you can include as many Mixins as you want.
Mixins can have as many methods as you want and this all works great, so
we do have to be a little careful here.
I was so careful to precisely define method look-up.
Now that we have other ways to add methods to classes.
It turns out Ruby has to have written out a bunch of rules on how you look up
a method m.
What if multiple Mixins define the method?
What if the Mixin defines it and the class defines it and so on?
So just so you know, here's the rule.
When you are looking for a method M for some object obj,
so that you can call the method, you look in obj's class.
Then you look at and in mixins that it includes.
Then you look in the super class, then any Mixins, then that super class includes.
Then the super super class and so on.
So, you check the class definition, then the Mixins and turns out you check
the Mixins in order or a later include will shadow any earlier includes.
I will not test you on that.
I just wanted you to know that as part of a language definition you have
to resolve these issues and so, Ruby did.
As for instance variables, Mixin methods can get or set instance variables.
If they do, those instance variables are part of the regular class.
So, if methods from two different mixins both try to
use the same instance variable, they could mess each other up.
So, many people consider it poor style for
a mixin method to access instance variables in any way.
On the other hand, in other situations it is what you need to do or want to do.
So, I will not resolve that style issue.
I will just tell you that in terms of semantics, Mixin methods can
access instance variables of the object they are a part of.
So now that we've seen what Mixins are,
let me show you what everyone really loves about them in Ruby.
Turns out there's two Mixins that are just widely used and
they make you smile, because they really make it easier to program.
The first one is a Mixin called comparable and here's what it does.
It defines methods less than, greater than, equals, not equals, greater than or
equal to, or less than or equal to.
And it assumes that any class that includes it defines just one thing,
which is this three-way comparison operator.
This is sometimes called the spaceship operator and what you're supposed to do
with the spaceship operator is have it take two arguments.
And return a negative number if the one on the left is less.
Zero if they're both equal and
a positive number if the one on the right is less, so let me just show that to you.
I can show that to you just with numbers.
The spaceship operator is defined.
The number is three, spaceship four is -1,
3 spaceship 3 is 0 and 3 spaceship 2 is 1.
So it turns out that on numbers, when you say is three less than two,
and you get false.
That is actually implemented by the comparable mix-in defining less than,
to call the spaceship operator.
All it's doing is it's finding less than to call the spaceship operator and then,
see if the result is less than one.
And if it is, then you return true.
Otherwise, you return false.
Let's do that for our own class.
I have an example here.
I have a little class name.
All right, so name has three kind of fields, instance variables, first,
middle and last.
Here is an initializer where you pass in first, last, and middle name.
And then, I define the spaceship operator.
I define the spaceship operator.
Take one other argument, the thing I'm comparing against and
there's a bunch of logic here.
I compare the last name if the last names are equal.
I compare the first names.
If the first names are equal, I compare the middle name, and
I do all that using this spaceship operator on strings.
Which is defined, which is what all these are doing, okay?
And so, this is defined, so in fact,
I already have over here, I already defined two names.
N1 is Daniel Joseph Grossman, although I got it first, last, middle,
that's not actually my name.
And I made the same mistake here on n2 for Barack Obama Hussein,
instead of Barack Hussein Obama but that doesn't matter.
I have these two names and the spaceship operator is defined on them.
So if I ask n1 spaceship n2 I get one, and
if ask n2 spaceship n1 I get minus 1.
If I ask n1 spaceship n1 I get 0, that's all fine,
its a proper comparison but I can ask all other operators too.
I can ask n1==n2, I can ask n1 not equal n2.
The whole reason I can do that is just one line
where in name I said include comparable,
which defines all those other operators by having them call the space ship operator.
That's what Mixins are all about, so
let me show you the other main one that I think is even cooler.
Now this one's called enumerable, so enumerable defines a lots of iterators.
Lots of those high order methods that take blocks in terms of each.
All you have to do as the class
implementor who's including enumerable is, define each.
And then, you get all the other ones for free, so
I have an example of that as well.
I've defined my own little range class.
Of course, you wouldn't do this, because ranges are built into Ruby just fine, but
this range class defines each.
so the initialize methods sets a low and a high instance variable.
And then, what each does is, four low up to high actually using a wire loop.
It yields, so it calls the block with i then sets i = i + 1 and
goes around the loop again.
So, I've already created a couple of ranges over here.
r1 is the range from 3 to 7and r2 is the range from 5 to 12.
And of course, since I defined each, I can take R1 and I could say put S.
I could pass it a block that for each thing in the range.
Print it out and sure enough, I get three, four, five, six, seven and
if I did that with R2.
I would get five up through 12 But I also have all the other iterators too.
Comparable defines them all in terms of each.
So for example, count is defined in the comparable Mixin and
how about I count how many of the numbers are odd.
And I would get four, five, seven, nine, and 11.
If I ask it on r1, I think I'll only get three, three, five, and seven.
You have R1.map.
You have R1.any and so on.
They're all defined.
They were all included by comparable and they're all defined in terms of each.
The Mixin has no idea how to iterate through the elements of MyRange.
Except, that it knows to each, so just call each with the block and
then do the right thing with the result.
So, that is what everyone loves about Ruby mixins.
They are nice.
I think this is a wonderful thing.
You don't need the full power of multiple inheritance.
Ruby style mixins are enough, but they're not a full replacement for
multiple inheritance.
So let me just wrap up by saying, they would work fine for
our kind of 3D ColorPoints.
What I have over here in the code down at the bottom is,
suppose I defined a mixin color.
Now, this is controversial because it's using an instance variable @color.
But it defines a getter and a setter and a method darken.
Then what I could do is, my 3D points could subclass point, all right.
My color points could subclass point and include color.
And my 3D color points could subclass point 3D and include color.
And this will all workout and my 3D color points will have exactly the methods and
the behavior I want.
Because I only get one super class, but I can include any number of Mixins.
It does not work as well for artist cowboys.
So, if I want an artist cowboy, I want everything that an artist has.
Everything that a cowboy has, but it doesn't really make sense to me for
either artist or a cowboy to be a Mixin.
A color Mixin is arguably okay, but artist and
cowboy should really both be classes and if they're both classes.
You cannot inherit from both of them.
So that is why while Mixins are great, I think they're a really neat thing in Ruby.
I would never suggest that they are full replacement for multiple inheritance.
Explorer notre catalogue
Rejoignez-nous gratuitement et obtenez des recommendations, des mises à jour et des offres personnalisées.
Coursera propose un accès universel à la meilleure formation au monde,
en partenariat avec des universités et des organisations du plus haut niveau, pour proposer des cours en ligne.
© 2018 Coursera Inc. Tous droits réservés.
