[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.
Generics Versus Subtyping
Loading...
来自 University of Washington 的课程
Programming Languages, Part C
201 个评分
从本节课中
Section 10, Final Exam, and Course Wrap-Up
We have reached the last module of Programming Languages! We first study subtyping, how it relates to static types for object-oriented programming, and how it relates to generics. There is no assignment or quiz devoted only to this last "new material", but there is a "final exam" covering Part B and Part C of the course. Enjoy studying for the exam, and don't miss the final "wrap-up" lesson when you're all done!
与讲师见面
Dan GrossmanProfessor
Computer Science & Engineering
[MUSIC]
In the spirit of showing the complementary benefits of different approaches,
I want to finish by comparing generics, the the type variables we saw in ML,
with subtyping.
This is right up there in the course with comparing functional decomposition,
with OL decomposition or static typing versus dynamic typing.
And what we'll see is that generics and
subtyping are simply good at different things.
So let's start with what generics are good for.
We saw this in ML, so I'll present it in terms of ML.
They're great for functions that combine other functions.
For example, we were able to write the compose function in ML and
give it this beautiful type.
That's why they can take any function of type 'b -> 'c, and
any function of type 'a -> 'b, and it will return something that has type 'a -> 'c.
And these types can be instantiated with any type in our language.
It describes precisely what compose is doing.
We also saw that generics are great for
functions that operate over generic collections.
That a length function for lists can work for any type of list.
That the map function has type alpha arrow beta, an alpha list to beta list.
It doesn't care what the list elements are,
provided that the argument type of the function you pass expects that type.
So in general, we saw many other idioms,
generics are great when you have code that can work for any type of thing.
But some of the things have to be the same type, which is when you see 'a or
'b appear multiple times in a type, it expresses those type equalities.
So generics are great not just in functional programming,
that's why Java and C# also have generics.
They tend to be a little clumsier to use
because there isn't as much type inference.
They're often are little more difficult semantically because of how they
were added later to the language, and how they interact with OOP and objects.
But nonetheless, we even saw in an earlier optional lecture how to code
up things as fancy as closures or manual effective closures in Java.
And it's not so bad, and that's why people in Java and C# do use generic types
in al the situations that they're useful in ML where we saw them there.
Now, we didn't study Java, so you're not responsible for this syntax,
which no one tends to love.
But here is a very simple pair class in ML that even has a swap method.
And this class works for any type of things that go in the first component and
in the second component, which I've called x and y here, okay?
So you do not want to use subtyping in these situations that I've remarked here
generics are good at.
That if you try to use subtyping for things like a container,
like a pair, you just end up using the wrong thing everywhere.
What should the type of the fields of a pair be if you don't have generics?
All right, if you have to pick one type for all pairs, well,
I guess you would have to use something like object.
And that's what people did in Java back before Java had generics.
And it's really unfortunate.
It's really using the wrong programing languages tool for
the job, which is I guess what you have to do if you don't have the right tool.
Now we have the right tool in most of our statically typed languages and
you should use it.
What you end up doing is you end up putting on your
fields the components of your pair, that it has type object.
And thanks to subtyping, that's fine when you write to the fields,
when you create a pair.
You want to pass in a string?
No problem, string is a subtype of object.
You want to pass in a color point?
No problem.
Color point is a subtype of object.
But then when you get the fields back out, and let's be honest,
the only point of having a pair is to get it out at some point, right?
When you get it back out, all you know is that it has type object.
So there is nothing you can with it until you somehow
get back that it has some other type.
And in Java, and C#, we do that with a downcast.
This is basically a runtime check, that says, I actually think it's a string,
and if I'm right, please give me back of something of type string, and,
if I'm wrong, raise an exception.
So by having to put these downcasts in, we're not getting static checking,
those tests could fail, and we're paying the runtime cost of
actually doing the check, and we're making our code harder to read.
So it's kind of a lose-lose-lose compared to generics, and
that's because generics are better for this kind of programming.
Subtyping is great for other things.
There's some great uses of subtyping, which is sometimes, in fancier verbiage,
called subtype polymorphism, right?
Whenever you have some code that needs an object that behaves like a foo, and
you have some object that has more than a foo needs,
you have some subclass of foo that has a bunch of extra stuff, no problem.
It's great to be able to pass that in.
Generics don't have that idea, generics are about, I work for any type.
This is about saying no, I need a foo but if you have a subtype of foo, no problem.
So where does that come up?
As I've shown in this section repeatedly, there are many simple examples,
like something needs a point but you have a color point.
That color field is no concern to anyone.
Subtyping lets us capture that idea and generics don't.
The other canonical example where I think object oriented programing has just
been very, very successful is in programming graphical user interfaces.
Okay, so you have some super class which has ideas in it,
there's some super type that says anything of this type has
the ability to be on the screen to respond to mouse clicks, to be resized.
And some code can operate over anything with that type, but presumably,
the things actually being passed have much, much more, like a color,
and a default font and all sorts of menu bars and all that sort of stuff.
And subtyping feels like the right thing there.
That you have some code that only needs some things and
then you have some objects that have some more things, subtyping's great for that.
And if you try to do even simple things like points and
color-points in ML, it's frustrating.
Now, nothing's impossible, there's always some way to code it up if you're willing
to go through enough workarounds.
But ML really does not have subtyping.
So if you try to write in ML, this is actual ML code here,
a distance to the origin function, that takes in a record with an x field and
a y field, distance origin works just fine.
But its type is record with x of type real y of type real to real.
And if you've tried to call it with something that has extra fields,
it just doesn't type check.
The types are not equal, ML does not have subtypes,
it would make type inference more complicated and ML chose not to have it.
So you cannot call distToOrigin with this record.
Now what you could do if you're interested in a workaround, the same way in Java,
pre-generics, there were ways to do collections, they were just cumbersome.
Is you could change distToOrigin to not take an x:real, y:real at all.
To actually take anything of type alpha, but make the caller
pass in a getter for the x coordinate and a getter for the y coordinate.
And if you do that, then what you end up with is a function that has type
alpha arrow reel and alpha arrow reel and alpha to reel.
Make the caller pass in how to get the x coordinate and the y coordinate, and
then the actual v here can be anything you want.
And that's frustrating if most of your code just wants to do this with
plain old points, it would have to create a helper function that had the getter,
the right get x and get y.
But this code could actually be used with something that was a color point,
provided we passed in the appropriate getters.
And yet, because of the lack of subtyping in ML, you would
actually have to use different getters and setters for points and for color points.
You really cannot reuse code in ML for points and color points, and
that's because subtyping, which ML does not have, is the right tool for this task.
