DOC PREVIEW
UW CSE 341 - Lecture Notes

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

Save
View full document
View full document
Premium Document
Do you want full access? Go Premium and unlock all 16 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 16 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 16 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 16 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 16 pages.
Access to all documents
Download any document
Ad free experience
Premium Document
Do you want full access? Go Premium and unlock all 16 pages.
Access to all documents
Download any document
Ad free experience

Unformatted text preview:

'&$%CSE 341:Programming LanguagesDan GrossmanSpring 2004Lecture 22— Advanced Issues in Smalltalk and Other DynamicallyTyped OO LanguagesDan Grossman CSE341 Spring 2004, Lecture 22 1'&$%Where We AreWe have the basics:• Everything is an object.• Every object has a class.• An object’s behavior is determined by its class.• Subclassing inherits, extends, and overrides behavior.• self is resolved with late-binding (dynamic dispatch)This elegance leads to certain conveniences (good) and awkwardness(bad)...Dan Grossman CSE341 Spring 2004, Lecture 22 2'&$%Today’s “Advanced Issues”• convenience: classes-are-objects makes “factories” trivial• awkwardness: class of a class of a class...• awkwardness: “fragile” superclassesAnd there extensions with their own conveniences and awkwardenesses:• multiple inheritance• multimethods (next class)Next time we will start considering type-system issues for OO; todaywe can still send any message to any object.Dan Grossman CSE341 Spring 2004, Lecture 22 3'&$%Motivating the “Factory Pattern”Consider a Java method using a Windows GUI to do some stuff:void doStuff() {Frame f = new WindowsFrame(); // a subclass of Framef.addButton(...);f.displayMessage(...);...}And of course we have 100s of methods that build GUI objects in thisway.And now we want to be platform-independent (support Linux andApple, which use different subclasses for each kind of GUI thing).Dan Grossman CSE341 Spring 2004, Lecture 22 4'&$%What can we do?Options:• Duplicate 100s of methods• Pass a “platform” flag everywhere and use if-statements• Like previous but put flag in a global scope• Like previous but abstract if-statements to helper methodsEven with helper methods, the if-statements are very un-OO.Dan Grossman CSE341 Spring 2004, Lecture 22 5'&$%Using the “Factory Pattern”An OO solution uses “object factories”:abstract class FrameFactory { Frame makeFrame(); }class WindowsFrameFactory extends FrameFactory {Frame makeFrame() { return new WindowsFrame(); }}class LinuxFrameFactory extends FrameFactory {Frame makeFrame() { return new LinuxFrame(); }}...Now we can have a global g holding a FrameFactory and doStuffbegins with Frame f = g.makeFrame();.And we’ve written 3 classes before our first cup of coffee. :)Dan Grossman CSE341 Spring 2004, Lecture 22 6'&$%Convenience of First-Class ClassesWouldn’t it be easier to skip the factory classes and just:• Store in g either WindowsFrame or LinuxFrame• Change doStuff to begin Frame f = new g();Sure but you can’t do that in Java because classes aren’t objects. Itworks perfectly in Smalltalk (f := g new).An interesting connection to our equivalence lecture:• If new is just a mes sage and WindowsFrame is just an object, thensending makeFrame to WindowsFrameFactory is e quivalent tosending new to WindowsFrame• Just like (fn x => C x) is equivalent to C where C is a datatypeconstructor (if constructors-are-functions).Dan Grossman CSE341 Spring 2004, Lecture 22 7'&$%But if classes are objects...“Classes are objects” is great, but Java is avoiding some crazy stuffthat:• Doesn’t affect day-to-day Smalltalk-80 programming• Does affect the Smalltalk-80 definition and implementationHere’s the catch:• What is the class of 3? What is the class of ’hi mom’?• Okay, so what is the class of SmallInteger? Of String?– If the same class (Smalltalk-76, Java), then they share methodsbecause class methods are class-class instance methods.– Class (static) methods in Java are specialBut we’re not done...Dan Grossman CSE341 Spring 2004, Lecture 22 8'&$%Metaclasses• Okay, what is the class of SmallInteger class? Of StringIntegerclass?– If we keep stuff separate forever, we’ll have an infinite numberof classes!• Okay, so what is the class of Metaclass?• Okay, so what is the class of Metaclass class?Clever, huh? But the “instance-of relation” ends in a cycle!Moral: Even elegant systems often have their “dark corners”Dan Grossman CSE341 Spring 2004, Lecture 22 9'&$%Fragile Su perclassesA common problem in OO languages: What if you want/need tochange a class that has been subclassed? “No problem?”• What if you add a method (new functionality, shared helper, etc.)• What if you “optimize” a method implementation?• What if, as a result, you can remove a method?Bottom line: inheritance reuses implementations; and there is littlecontrol over how subclasses reuse public methods and extend objects.For the latter, distinguishing “add” vs. “override” can improve thesituation (s ee C# “versions” for example)Dan Grossman CSE341 Spring 2004, Lecture 22 10'&$%Multiple InheritanceIf code reuse via inheritance is so useful, why not allow multiplesuperclasses?• C++ does, Java and Smalltalk don’t• Because it causes some semantic awkwardness andimplementation awkwardness (we’ll discuss only the former)• Because it can interact awkwardly with static typing (not today)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 superclassesDan Grossman CSE341 Spring 2004, Lecture 22 11'&$%Multiple Inheritance Semantic ProblemsWhat if multiple superclasses define the same message m or field f ?Options for m:• Reject subclass—too restrictive (the diamond problem)• “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(diamonds)Beyond this course: Other ways to compose behavior (e.g., mixins)Dan Grossman CSE341 Spring 2004, Lecture 22 12'&$%Multimethod sRemember our semantics for message send (with late-binding):1. We use the receiver’s class to determine what method to call.2. We evaluate the method body in an e nvironment with self boundto the receiver and the arguments bound to the parameters.The second step does not really make self so special; we couldrequire methods to give an explicit name for this “0th” argument.The first step does make self special; the classes of the otherarguments does not affect what method we call.Multimethods let us do just that!Dan Grossman CSE341 Spring 2004, Lecture 22 13'&$%Why multimethodsConsider these reasonable


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?