DOC PREVIEW
UW CSE 341 - Lecture Notes

This preview shows page 1 out of 3 pages.

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

Unformatted text preview:

CSE341: Programming Languages Lecture 19 Introduction To Ruby; Dynamic OOP; "Duck Typing" Dan Grossman Fall 2011 The plan • Will still use Racket for some more topics, but first get up-to-speed on Ruby – Do now to better align with homework and section schedule • Lecture materials may not recount every little language feature we use – Thomas book (2nd edition, Chapters 1-9) quite readable • Can skip/skim regexps and ranges • Also see online library documentation [large, searchable] • Focus in class will be on OOP, dynamic typing, blocks, mixins Fall 2011 2 CSE341: Programming Languages Logistics • We will use Ruby 1.8.7 – Ruby 1.9 is not compatible, but not hugely different – "The real world" is still using both a lot – Homework 6's graphics (mandatory) won't work with 1.9 • Installation instructions, etc. on course web-page – Can run programs with a REPL called irb • Homework 6 is about understanding and extending an existing program in an unfamiliar language – Good practice; different than previous homeworks – Read code: determine what you do and don't (!) need to know Fall 2011 3 CSE341: Programming Languages Ruby • Pure object-oriented: all values are objects (even numbers) • Class-based: Every object has a class that determines behavior – Like Java, unlike Javascript – Mixins (neither Java interfaces nor C++ multiple inheritance) • Dynamically typed • Convenient reflection: Run-time inspection of objects • Blocks and libraries encourage lots of closure idioms • Syntax and scoping rules of a "scripting language" – Often many ways to say the same thing – Variables "spring to life" on use – Lots of support for string manipulation [we won't do this] • Popular for building server-side web applications – But we won't discuss Ruby on Rails Fall 2011 4 CSE341: Programming Languages Where Ruby fits Note: Racket also has classes and objects when you want them – In Ruby everything uses them (at least implicitly) Historical note: Smalltalk also a dynamically typed, class-based, pure OOP language with blocks and convenient reflection – Smaller just-as-powerful language – Contrast Ruby's "why not add that" attitude • Probably less elegant; perhaps more useful Dynamically typed OO helps identify OO's essence by not having to discuss types Fall 2011 5 CSE341: Programming Languages dynamically typed statically typed functional Racket SML object-oriented Ruby Java Defining a class [For full code details and various expression constructs, see lec19.rb] Fall 2011 6 CSE341: Programming Languages class Rational = # no instance variable (field) decls # just assign to @foo to create field foo def initialize (num,den=1) … @num = num @den = den end def print … end def add r … end … endUsing a class • ClassName.new(args) creates a new instance of ClassName and calls its initialize method with args • Every variable holds an object (possibly the nil object) – Local variables (in a method) foo – Instance variables (fields) @foo – Class variables (static fields) @@foo • You use an object with a method call – Also known as a message send – Every object has a class, which determines its behavior • Examples: x.m 4 x.m1.m2(y.m3) -42.abs – m and m(…) are sugar for self.m and self.m(…) – e1 + e2 is sugar for e1.+(e2) (really!) Fall 2011 7 CSE341: Programming Languages Method / variable visibility • private: only available to object itself • protected: available only to code in the class or subclasses • public: available to all code This is different than what the words mean in Java • All instance variables and class variables are private • Methods are public by default – There are multiple ways to change a method's visibility Fall 2011 8 CSE341: Programming Languages Some syntax / scoping gotchas • You create variables (including instance variables) implicitly by assigning to them – So a mis-spelling just creates a new variable – Different instances of a class could have different fields • Newlines matter – Often need more syntax to put something on one line – Indentation is only style (not true in some languages) • Class names must be capitalized • Message sends with 0 or 1 argument don't need parentheses • self is a special keyword (Java's this) Fall 2011 9 CSE341: Programming Languages Getters and setters • If you want outside access to get/set instance variables, must define methods • The foo= convention allows sugar via extra spaces when using the method • Shorter syntax for defining getters and setters is: • Overall, requiring getters and setters is more uniform and more OO – Can change the methods later without changing clients – Particular form of change is subclass overriding [next lecture] Fall 2011 10 CSE341: Programming Languages def foo @foo end def foo= a @foo = a end x.foo = 42 x.foo attr_writer :foo attr_reader :foo Top-level • Expressions at top-level are evaluated in the context of an implicit "main" object with class Object • That is how a standalone program would "get started" rather than requiring an object creation and method call from within irb • Top-level methods are added to Object, which makes them available everywhere Fall 2011 11 CSE341: Programming Languages Class definitions are dynamic • All definitions in Ruby are dynamic • Example: Any code can add or remove methods on existing classes – Very occasionally useful (or cute) to add your own method to the Array class for example, but it is visible to all arrays • Changing a class affects even already-created instances • Disastrous example: Changing Fixnum's + method • Overall: A simple language definition where everything can be changed and method lookup uses instance's classes Fall 2011 12 CSE341: Programming LanguagesDuck Typing "If it walks like a duck and quacks like a duck, it's a duck" – Or don't worry that it may not be a duck When writing a method you might think, "I need a Foo argument" but really you need an object with enough methods similar to Foo's methods that your method works – Embracing duck typing is always making method calls rather than assuming/testing the class of arguments Plus: More code reuse; very OO approach – What messages an object receive is all that matters


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?