DOC PREVIEW
UW CSE 341 - Lecture Notes

This preview shows page 1-2-3-4 out of 11 pages.

Save
View full document
View full document
Premium Document
Do you want full access? Go Premium and unlock all 11 pages.
Access to all documents
Download any document
Ad free experience
View full document
Premium Document
Do you want full access? Go Premium and unlock all 11 pages.
Access to all documents
Download any document
Ad free experience
View full document
Premium Document
Do you want full access? Go Premium and unlock all 11 pages.
Access to all documents
Download any document
Ad free experience
View full document
Premium Document
Do you want full access? Go Premium and unlock all 11 pages.
Access to all documents
Download any document
Ad free experience
Premium Document
Do you want full access? Go Premium and unlock all 11 pages.
Access to all documents
Download any document
Ad free experience

Unformatted text preview:

'&$%CSE 341:Programming LanguagesHal PerkinsSpring 2011Lecture 22— Multiple Inheritance, Interfaces, MixinsHal Perkins CSE341 Spring 2011, Lecture 22 1'&$%TodayHave seen OO’s essence: inheritance, overriding, dynamic-dispatch.What if we want these things from more than “exactly 1 superclass”?• Multiple inheritance: allow > 1 superclasses– Useful but has some problems (see C++)• Java-style interfaces: allow > 1 types– “Irrelevant” in a dynamically typed language, but fewerproblems• Mixins: allow > 1 “sources of methods”– Close to multiple inheritance; almost as useful with fewer (?)problems– In RubyHal Perkins CSE341 Spring 2011, Lecture 22 2'&$%Multiple InheritanceIf code reuse via inheritance is so useful, why not allow multiplesuperclasses?• Because it causes some semantic awkwardness andimplementation awkwardness (we’ll discuss only the former)• (With static typing, there are some more issues)Is it useful? Sure: A simple example is “3DColorPoint” assuming wealready have “3DPoint” and “ColorPoint”.Naive view: Subclass has all fields and methods of all superclassesHal Perkins CSE341 Spring 2011, Lecture 22 3'&$%Trees, dags, and diamondsThe “class hierarchy” is a (conceptual) graph with edges fromsubclasses to superclasses.Ambiguous phrase: subclass, let’s use immediate-subclass ortransitive-subclass when we need to be clear.• With single inheritance, the class hierarchy is a tree.• With multiple inheritance, the class hierarchy is a dag.– Semantic problems arise from diamonds: Multiple ways toshow that class A is a transitive-subclass of some class B.– If all classes are transitive-subclasses of something like Object,then multiple inheritance always leads to diamonds.Hal Perkins CSE341 Spring 2011, Lecture 22 4'&$%Multiple Inheritance Semantic ProblemsWhat if multiple superclasses define the same message m or field f ?• Classic example: Artists, Cowboys, and ArtistCowboysOptions for m:• Reject subclass—too restrictive (especially due to diamonds)• “Left-most superclass wins” (leads to silent weirdness and reallywant per-method flexiblity)• Require subclass to override m (can use directed resends)Options for f: one copy or two copies?C++ provides two forms of inheritance:• One always makes two copies• One makes one copy if fields were declared by same class– Would not work well in Ruby?Hal Perkins CSE341 Spring 2011, Lecture 22 5'&$%Java-style interfaces(Recall?) in Java, we can define interfaces and classes can implementthem.• Interface describes methods and their typesinterface Example {void m1(int x, int y);Foo m2(Example e, String s);}• Example is a type (can be used for a field, method argument,local variable, etc.)• If class C implements interface I, then instances of C can have typeI but C must define everything in I (directly or via inheritance).• Given an expression of type I, it type-checks to send it anymessage I promises.Hal Perkins CSE341 Spring 2011, Lecture 22 6'&$%Interfaces are a typing thingIn Java, you have 1 immediate-superclass and any number ofinterfaces you implement.Because interfaces provide no methods or fields (only types ofmethods), no duplication problems result!• No problem if I1 and I2 both “promise” some method m and Cimplements I1 and I2.But interfaces do not give us the power we want for making colored3D points or artist-cowboys.They’re totally irrelevant in a dynamically typed language like Ruby:• We are already allowed to send any message to any object• It is up to us to get it right (“interfaces” more in comments orreflection, e.g., the methods method of Object)Hal Perkins CSE341 Spring 2011, Lecture 22 7'&$%Interfaces vs. Abstract ClassesIf you had multiple inheritance, you could replace interfaces withabstract classes containing only abstract methods.• Called pure virtual methods in C++• But the whole point is multiple inheritance is more powerfulbecause it doesn’t require n − 1 superclasses to have onlyabstract methods.Hal Perkins CSE341 Spring 2011, Lecture 22 8'&$%MixinsA mixin is a collection of methods• no fields, constructors, instances, etc.Languages with mixins (e.g., Ruby) typically allow a class to have 1superclass but any number of mixins.Bad news: Less powerful than multiple inheritance; have to decide“upfront” what is a class and what is a mixin.Good news: Clear semantics on methods/fields and works great forcertain idioms.Hal Perkins CSE341 Spring 2011, Lecture 22 9'&$%Ruby mixin basicsA module’s instance methods are mixed into a class by including themodule in the class definition.Method-lookup rules: First class’s methods, then its mixins’ methods(later includes shadow), then immediate-superclass, thenimmediate-superclass’s mixins, ...Field rules: It is all one object.Hal Perkins CSE341 Spring 2011, Lecture 22 10'&$%What mixins are good forWe could make Color a mixin and then use it for coloring 2D and 3Dpoints.• Works fine but often bad style to have mixin methods define fields(could conflict with other fields)For artist-cowboys, what should the mixin be?But mixins are extremeley elegant for letting classes “get a bunch ofmethods while defining only a few”.• All thanks to late-binding!• Cool examples in Ruby library: Comparable and EnumerableHal Perkins CSE341 Spring 2011, Lecture 22


View Full Document

UW CSE 341 - Lecture Notes

Documents in this Course
Macros

Macros

6 pages

Macros

Macros

6 pages

Macros

Macros

3 pages

Mutation

Mutation

10 pages

Macros

Macros

17 pages

Racket

Racket

25 pages

Scheme

Scheme

9 pages

Macros

Macros

6 pages

Load more
Download Lecture Notes
Our administrator received your request to download this document. We will send you the file to your email shortly.
Loading Unlocking...
Login

Join to view Lecture Notes and access 3M+ class-specific study document.

or
We will never post anything without your permission.
Don't have an account?
Sign Up

Join to view Lecture Notes 2 2 and access 3M+ class-specific study document.

or

By creating an account you agree to our Privacy Policy and Terms Of Use

Already a member?