DOC PREVIEW
UW CSE 341 - Lecture Notes

This preview shows page 1-2-19-20 out of 20 pages.

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

Unformatted text preview:

Slide 1TodayResolving identifiersRuby instance variables and methodsMethod names are differentRuby message lookupJava method lookup (very similar)The punch-line againComments on dynamic dispatchA simple example, part 1A simple example, part 2The OOP trade-offManual dynamic dispatchOur approachA point object bound to xKey helper functions(send x 'distToOrigin)Constructing points"Subclassing"Why not ML?CSE341: Programming LanguagesLecture 21Late Binding;OOP as a Racket PatternDan GrossmanFall 2011TodayDynamic dispatch aka late binding aka virtual method calls–Call to self.m2() in method m1 defined in class C can resolve to a method m2 defined in a subclass of C–Most unique characteristic of OOPNeed to define the semantics of objects and method lookup as carefully as we defined variable lookup for functional programmingThen consider advantages, disadvantages of dynamic dispatchThen encoding OOP / dynamic dispatch with pairs and functions–In Racket–Complement Lecture 9's encoding of closures in Java or CFall 2011 2CSE341: Programming LanguagesResolving identifiersThe rules for "looking up" various symbols in a PL is a key part of the language's definition–So discuss in general before considering dynamic dispatch•ML: Look up variables in the appropriate environment–Key point of closures' lexical scope is defining "appropriate"–Field names (for records) are different•Racket: Like ML plus let, letrec, and hygienic macros•Ruby: –Local variables and blocks mostly like ML and Racket–But also have instance variables, class variables, and methods (all more like record fields)Fall 2011 3CSE341: Programming LanguagesRuby instance variables and methods•self maps to some "current" object•Look up local variables in environment of method•Look up instance variables using object bound to self•Look up class variables using object bound to self.classA syntactic distinction between local/instance/class means there is no ambiguity or shadowing rules–Contrast: Java locals shadow fields unless use this.fBut there is ambiguity/shadowing with local variables and zero-argument no-parenthesis calls–What does m+2 mean? •Local shadows method if exists unless use m()+2•Contrast: Java forces parentheses for syntactic distinctionsFall 2011 4CSE341: Programming LanguagesMethod names are different•self, locals, instance variables, class variables all map to objects•Have said "everything is an object" but that's not quite true:–Method names (more like ML field names)–Blocks–Argument lists•First-class values are things you can store, pass, return, etc.–In Ruby, only objects (almost everything) are first-class–Example: cannot do e.(if b then m1 else m2 end) •Have to do if b then e.m1 else e.m2 end –Example: can do (if b then x else y).m1Fall 2011 5CSE341: Programming LanguagesRuby message lookupThe semantics for method calls aka message sendse0.m(e1,…,en)1. Evaluate e0, e1, …, en to objects obj0, obj1, …, objn–As usual, may involve looking up self, variables, fields, etc.2. Let C = the class of obj0 (every object has a class)3. If m is defined in C, pick that method, else recur with the superclass of C unless C is already Object–If no m is found, call method_missing instead•Definition of method_missing in Object raises an error4. Evaluate body of method picked:–With formal arguments bound to obj1, …, objn–With self bound to obj0 -- this implements dynamic dispatch!Note: Step (3) complicated by mixins: will revise definition laterFall 2011 6CSE341: Programming LanguagesJava method lookup (very similar)Fall 2011 7CSE341: Programming LanguagesThe semantics for method calls aka message sendse0.m(e1,…,en)1. Evaluate e0, e1, …, en to objects obj0, obj1, …, objn–As usual, may involve looking up this, variables, fields, etc.2. Let C = the class of obj0 (every object has a class)3. [Complicated rules to pick "the best m" using the static types of e0, e1, …, en]–Static checking ensures an m, and in fact a best m, will always be found–Rules similar to Ruby except for this static overloading–No mixins to worry about (interfaces irrelevant here)4. Evaluate body of method picked:–With formal arguments bound to obj1, …, objn–With this bound to obj0 -- this implements dynamic dispatch!The punch-line againe0.m(e1,…,en)To implement dynamic dispatch, evaluate the method body with self mapping to the receiver•That way, any self calls in the body use the receiver's class, –Not necessarily the class that defined the method•This much is the same in Ruby, Java, C#, Smalltalk, etc.Fall 2011 8CSE341: Programming LanguagesComments on dynamic dispatch•This is why last lecture's distFromOrigin2 worked in PolarPoint–distFromOrigin2 implemented with self.x, self.y–If receiver's class is PolarPoint, then will use PolarPoint's x and y methods because self is bound to the receiver•More complicated than the rules for closures–Have to treat self specially–May seem simpler only because you learned it first–Complicated doesn't imply superior or inferior•Depends on how you use it…•Overriding does tend to be overusedFall 2011 9CSE341: Programming LanguagesA simple example, part 1In ML (and other languages), closures are closedSo we can shadow odd, but any call to the closure bound to odd above will "do what we expect"–Doesn't matter if we shadow even or notFall 2011 10CSE341: Programming Languagesfun even x = if x=0 then true else odd (x-1) and odd x = if x=0 then false else even (x-1)(* does not change odd – too bad; this would improve it *)fun even x = (x mod 2)=0(* does not change odd – good thing; this would break it *)fun even x = falseA simple example, part 2In Ruby (and other languages), subclasses can change the behavior of methods they don't overrideFall 2011 11CSE341: Programming Languagesclass A def even x if x==0 then true else odd (x-1) end end def odd x if x==0 then false else even (x-1) end endendclass B < A # improves odd in B objects def even x ; x % 2 == 0 endendclass C < A # breaks odd in C objects def even x ; false endendThe OOP trade-offAny method that makes calls to overridable methods can have its behavior changed in subclasses even if it is not overridden–Maybe on purpose, maybe by mistake•Makes it harder to reason about "the code you're looking at"–Can avoid by disallowing overriding (Java final) of helper methods you call•Makes it easier for subclasses to specialize


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?