Object-Oriented Programming Languages: Application and Interpretation Éric Tanter August 24, 2020 last updated: Monday, August 24th, 2020 Copyright © 2010-2020 by Éric Tanter The electronic version of this work is licensed under the Creative Commons Attribution Non-Commercial No Derivatives License This booklet exposes fundamental concepts of object-oriented programming languages in a constructive and progressive manner. It follows the general approach of the PLAI book by Shriram Krishnamurthi (or at least I’d like to think it does). The document assumes familiarity with the following Parts of PLAI: I-V (especially first-class functions, lexical scoping, recursion, and state), as well as XII (macros). OOPLAI is also available in PDF version. Note however that OOPLAI is subject to change at any time, so accessing it through the web is the best guarantee to be viewing the latest version. I warmly welcome comments, suggestions and fixes; just send me a mail! As of June 2018, OOPLAI has been translated to Chinese by ChongKai Zhu. Acknowledgments: I am thankful to the members of the PLEIAD lab and the students of the Programming Languages course at University of Chile for detecting bugs and suggesting enhancements. 1 1 From Functions to Simple Objects This exploration of object-oriented programming languages starts from what we know al- ready from PLAI, as well as our intuition about what objects are. 1.1 Stateful Functions and the Object Pattern An object is meant to encapsulate in a coherent whole a piece of state (possibly, but not necessarily, mutable) together with some behavior that relies on that state. The state is usually called fields (or instance variables), and the behavior is provided as a set of methods. Calling a method is often considered as message passing: we send a message to an object, and if it understands it, it executes the associated method. In higher-order procedural languages like Scheme, we have seen similar creatures: (define add (λ (n) (λ (m) (+mn)))) >(define add2(add2)) >(add25) 7 The function add2 encapsulates some hidden state (n=2 ) and its behavior effectively de- pends on that state. So, in a sense, a closure is an object whose fields are its free variables. What about behavior? well, it has a unique behavior, triggered when the function is applied (from a message passing viewpoint, apply is the only message understood by a function). If our language supports mutation (set!), we can effectively have a stateful function with changing state: (define counter (let([count0]) (λ () (begin (set! count(add1 count)) count)))) We can now effectively observe that the state of counter changes: >(counter) 1 2 >(counter) 2 Now, what if we want a bi-directional counter? The function must be able to do either +1 or -1 on its state depending on... well, an argument! (define counter (let([count0]) (λ (msg) (match msg ['dec(begin (set! count(sub1 count)) count)] ['inc(begin (set! count(add1 count)) count)])))) Note how counter uses cmd to discriminate what action to perform. >(counter 'inc) 1 >(counter 'dec) 0 This looks quite like an object with two methods and one instance variable, doesn’t it? Let us generalize a bit, in order to support multiple arguments and organize methods as a list of functions indexed by their name. We will also introduce another instance variable step for controlling the amount by which the counter is increased or decreased. We add a few more methods as well: (define counter (let([count0] [step1]) (let([methods (list (cons 'inc( λ ()(set! count(+ count step)) count)) (cons 'dec( λ ()(set! count(- count step)) count)) (cons 'reset( λ ()(set! count0))) (cons 'step!( λ (v)(set! stepv))))]) (λ (msg. args) (let([found(assoc msg methods)]) (if found 3 (apply(cdr found) args) (error "message not understood:" msg))))))) We use the dot notation for the arguments of the dispatch function: this enables the function to receive one mandatory argument (the msg) as well as zero or more optional arguments (available in the body as a list bound to args). To define the dispatch function in a generic fashion, we first put all methods in an association list (ie. a list of pairs) called methods, which associates a symbol (aka. message) to the corresponding method (ie. a lambda). We use assoc to lookup an existing method for handling the msg. We get the result as found, which will be a pair symbol-lambda if found. We then use apply to apply the function to the (possibly empty) list of arguments. If no method was found, found will be #f; in that case, we generate an informative error message. Let’s try that: >(counter 'inc) 1 >(counter 'step!2) >(counter 'inc) 3 >(counter 'dec) 1 >(counter 'reset) >(counter 'dec) -2 >(counter 'hello) message not understood: hello 1.2 A (First) Simple Object System in Scheme We can now use macros to embed a simple object system that follows the pattern identified above. Note that in this booklet, we use (defmac(OBJECT([field fname fval] ...) defmac to define macros. defmac is ([method mname mparams mbody ...] ...)) like #:keywords field method define-syntax-rule, (let([fname fval] ...) but it also supports (let([methods(list(cons 'mname( λ mparams mbody ...)) ...)]) the specification of keywords and (λ (msg. args) captures of (let([found(assoc msg methods)]) identifiers (using (if found the #:keywords and #:captures (apply(cdr found) args) optional (error "message not understood:" msg))))))) parameters). It is provided by the play package. 4 We additionally define a specific notation for sending a message to an object, using an arrow Ñ, such as (Ñ counter step!3) . This little macro hides from the user the fact that an object is a function and that the message is treated as a symbol. (defmac( Ñ om arg ...) (o 'm arg ...)) We can now use our embedded object system to define our counter in a nice way: (define counter (OBJECT ([field count0] [field step1]) ([method inc()(set! count(+ count step)) count] [method dec()(set! count(- count step)) count] [method reset()(set! count0)] [method step!(v)(set! stepv)]))) and use it: >( Ñ counter inc) 1 >( Ñ counter step!2) >( Ñ counter inc) 3 >( Ñ counter dec) 1 >( Ñ counter reset) >( Ñ counter dec) -2 >( Ñ counter hello) message not understood: hello Note that object fields (like count and step) are strongly encapsulated here. There is no way to access them directly without going through a method. 1.3 Constructing Objects Up to now, our objects have been created as unique specimen. What if we want more than one point object, possibly with different initial coordinates? In the context of functional programming, we have already seen how to craft various similar functions in a proper way: we can use a higher-order function, parameterized accordingly, whose role is to produce the specific instances we want. For instance, from the add function defined previously, we can obtain various single-argument adder functions: 5 >(define add4(add4)) >(define add5(add5)) >(add41) 5 >(add51) 6 Because our simple object system is embedded in Scheme, we can simply reuse the power of higher-order functions to define object factories: This approach can also be used in (define(make-counter[init-count0][init-step1]) object-based languages such as (OBJECT JavaScript (JS has ([field count init-count] various ways to [field step init-step]) create similar objects). ([method inc()(set! count(+ count step)) count] [method dec()(set! count(- count step)) count] [method reset()(set! count0)] [method step!(v)(set! stepv)]))) The make-counter function takes the initial count and step as optional parameters, and returns a freshly created object, properly initialized. >(let([c1(make-counter)] [c2(make-counter 105)]) (+( Ñ c1 inc)( Ñ c2 inc))) 16 1.4 Dynamic Dispatch and Polymorphism Our simple object system is sufficient to show the fundamental aspect of object-oriented programming: dynamic dispatch, which gives rise to the kind of polymorphism that makes object-oriented programs extensible. See how the inc-all function below sends the inc message to each object in the list lst, without knowing how it will handle it (assuming it can!): (define(inc-all lst) (map( λ (x)( Ñ x inc)) lst)) >(inc-all(list(make-counter) (make-counter 105) (OBJECT()((method inc() "hola"))))) '(1 15 "hola") 6 In particular, the last object is not at all a counter, it just happens to be a weird object that handles inc in its own distinctive way. inc-all is completely oblivious to the kinds of objects it talks to. Likewise, notice how, in the following object-oriented implementation of a tree, a node object sends the sum message to each of its children without knowing whether it is a leaf or a node: (define(make-nodelr) (OBJECT ([field leftl] [field rightr]) ([method sum()(+( Ñ left sum)( Ñ right sum))]))) (define(make-leafv) (OBJECT ([field valuev]) ([method sum() value]))) >(let([tree(make-node (make-node(make-leaf3) (make-node(make-leaf 10) (make-leaf4))) (make-leaf1))]) (Ñ tree sum)) 18 We have successfully embedded a simple object system in Scheme that shows the connec- tion between lexically-scoped first-class functions and objects. However, we are far from done, because the object system we have is still incomplete and primitive. In particular, objects lack their "self" so far, and we have no advanced reuse mechanism yet. However, as simple as it may seem, this object system is entirely enough to illustrate the fundamental data abstraction mechanism that objects really are. See the chapter on the benefits and limits of objects for more on this matter. 7 2 Looking for the Self In the previous section, we have built a simple object system, whose main limitation is that objects are not "aware" of themselves.