DOC PREVIEW
UW CSE 341 - Late Binding

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:

CSE341: Programming Languages Lecture 21 Late Binding; OOP as a Racket Pattern Dan Grossman Fall 2011Today Dynamic 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 OOP Need to define the semantics of objects and method lookup as carefully as we defined variable lookup for functional programming Then consider advantages, disadvantages of dynamic dispatch Then encoding OOP / dynamic dispatch with pairs and functions – In Racket – Complement Lecture 9's encoding of closures in Java or C Fall 2011 2 CSE341: Programming LanguagesResolving identifiers The 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 3 CSE341: 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.class A syntactic distinction between local/instance/class means there is no ambiguity or shadowing rules – Contrast: Java locals shadow fields unless use this.f But 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 distinctions Fall 2011 4 CSE341: 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).m1 Fall 2011 5 CSE341: Programming LanguagesRuby message lookup The semantics for method calls aka message sends e0.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 error 4. 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 later Fall 2011 6 CSE341: Programming LanguagesJava method lookup (very similar) Fall 2011 7 CSE341: Programming Languages The semantics for method calls aka message sends e0.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 again e0.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 8 CSE341: 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 overused Fall 2011 9 CSE341: Programming LanguagesA simple example, part 1 In ML (and other languages), closures are closed So 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 not Fall 2011 10 CSE341: Programming Languages fun 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 2 In Ruby (and other languages), subclasses can change the behavior of methods they don't override Fall 2011 11 CSE341: Programming Languages class 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 end end class B < A # improves odd in B objects def even x ; x % 2 == 0 end end class C < A # breaks odd in C objects def even x ; false end endThe OOP trade-off Any 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 behavior without copying code – Provided method in superclass isn't modified later Fall 2011 12 CSE341: Programming LanguagesManual dynamic dispatch Rest of lecture: Write Racket code with


View Full Document

UW CSE 341 - Late Binding

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 Late Binding
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 Late Binding 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 Late Binding 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?