Software Composition ParadigmsSommersemester 2015

Radu Muschevici

Software Engineering Group, Department of Computer Science

2015-04-28

1 / 22

Exam Date

The exam date has changed to:

▶ Wednesday, 15 July 2015, 19.00–21.00▶ Rooms S101/A1 and S311/08

Note: The lecture on Tuesday, 7 July 2015 will be used for review andquestions (no new content).

2 / 22

Prototype-basedProgramming

3 / 22

Self: The Movie

Watch the Self 1 programming language video:https://www.youtube.com/watch?v=Ox5P7QyL774

1http://www.selflanguage.org/4 / 22

Prototype-based Programming Languages

Prototype: an original or first model of something from which otherforms are copied or developed

[Merriam-Webster Dictionary]

▶ No classes; only objects▶ Any object can be the prototype of another object▶ Object creation by copying the prototype▶ Objects define their own properties and methods▶ Objects delegate behaviour to other objects

Many languages (but only few used outside research):JavaScript, Self, Io, NewtonScript, Omega, Cecil, Lua, Object-Lisp,Exemplar, Agora, ACT-I, Kevo, Moostrap, Obliq, Garnet

5 / 22

Design Goals

Simplicity▶ Leave out everything that dilutes the paradigm▶ Everything is an object▶ Fewer concepts ⇒ simpler programming model, easier to

understand, explain and use▶ Simpler relationship between objects: object inherits from other

object (Compare to class-based, where 1: object is an instance ofa class, and 2: object’s class is a subclass of another class)

6 / 22

Example: The Object Model of SelfThe Self Object-Model� Every object contains a

collection of slots� Each slot has a name and an

object� Every slot can be marked as

parent slot� A non-method object simply

returns itself when invoked as a method

� A method objects contains a piece of code that’s executed on invocation

� Slots of method objects can be marked as argument slots

parent*

Íwidth:

7width

Íheight:

9height

paint:y

how to paint objects

:x

parent*

height:

^widthheight

width: x

:x

assignment primitivesoverwrite the corresponding

get methods

variables are modeled as methods returning

constant values

▶ Every object contains acollection of slots

▶ Each slot has a name and anobject

▶ Every slot can be marked asparent slot

▶ A non-method object simplyreturns itself when invoked asa method

▶ A method object contains apiece of code that’s executedon invocation

▶ Slots of method objects can bemarked as argument slots

7 / 22

Some Issues with Classes

“In OO programs, objects send messages to other objects. OO sourcecode shows us…classes inheriting from classes. Oops. There is acomplete disconnect in OOP between the source code and theruntime entities.”

[O. Nierstrasz, ECOOP 2010]

▶ Classes are abstract (“In the real world, there are only objects”)▶ Class-based languages force software engineers to design from

abstract to concrete▶ More natural: from concrete examples to abstract concepts▶ Class-based architectures are sometimes seen as too rigid▶ Designing a class inheritance hierarchy not always easy

8 / 22

Classification: An easy example

Three objects o1, o2, o3sharing properties a, b, c, d:

abc

o2

abd

o3

ab

o1

A corresponding class hierarchy:

abc

C2

abd

C3

ab

C1

o1 = new C1();o2 = new C2();o3 = new C3();

9 / 22

Family Resemblance: When classification is not easy

▶ Philosophical idea made popular by Wittgenstein (1889–1951)

▶ Observation: some things have no essential features in common,even though they may belong to same category.

▶ Instead they have a series of overlapping similarities.

▶ Members of a family are difficult to classify as a hierarchy.

▶ Examples: works of art, games, …

10 / 22

Family Resemblance: Example

Three objects: o1, o2, o3sharing some properties: a, b, c, d

abc

o1

bcd

o2

da

o3

11 / 22

Family Resemblance: Classification Attempt

abc

C1

bcd

C2

da

C3

a

A

b

B

c

C

d

D

bc

BC

12 / 22

Family Resemblance: Delegation

abc

o1 bcd

o2

da

o3

13 / 22

Prototypes & Object Creation

Prototypes▶ Any object can be the prototype for another object

Object Creation▶ By copying (cloning) an existing object (the prototype)▶ Some languages support object creation ex nihilo▶ Object is related to other objects through delegation

14 / 22

Delegation

▶ Mechanism to share data andbehaviour among objects

▶ An object has parent(s) (sometimethe prototype)

▶ If object receives a message it cannothandle, it delegates it to its parent(s)

▶ Multiple parents ⇒ multipleinheritance (diamond problem etc.)

▶ More flexible than inheritance

4 UNGAR AND SMITH

(class)

(superclass)

(inst vars)

(methods)

(name) Point

class, x, y

how to

(class)

(superclass)

(inst vars)

(methods)

(name) Object

nil

(none)

(class)

(y)

(x) 3

5

7

9

+ add points

how toprint print objects

x

x:

y

y:

parent*

3

!

5

!

x

x:

y

y:

parent*

7

!

9

!

+

parent*

print

how toadd points

how toprint objects

SELF objectsSmalltalk

. . .

. . .

instances and classes

Figure 1. A comparison of Smalltalk instances and classes with SELF objects.

At the bottom of each figure are two point objects that have been created by a user program.

Each SELF point intrinsically describesits own format, but appeals to anotherobject for any behavior that is sharedamong points. In this example, the pointsappeal to an object containing sharedbehavior for points. That object in turnappeals to another (on top) for behaviorthat is shared by all objects. This “root”object fully describes its own format andbehavior, so it has no parent.

Each Smalltalk point contains a classpointer and x and y coordinates. Theclass Point supplies both format (a list ofinstance variables) and behavior infor-mation (a collection of methods) forpoints. Additional format and behaviorinformation is inherited from Object viaPoint’s superclass link. Each of the twoclasses in turn must appeal to otherclasses (not shown) for their format andbehavior.

15 / 22

Object Creation: Flexibility

▶ Objects built from same prototype can differ in their behaviour▶ Objects can dynamically change state variables and behaviour

getArea() {width*height}

widthheight

rectangle

getArea() {width*width}

width

square

getVolume() {width*height*depth}

widthheightdepth

3dBox

clone + remove height+ change getArea() code

clone + add depth+ remove getArea()+ add getVolume()

16 / 22

Delegation: Flexibility (2)

▶ An object’s parent(s) can change dynamically

parent* ...

width 4

height 10

parent*

parent* ...

width 30

height 5

depth 12

17 / 22

Delegation: Flexibility (2)

▶ An object’s parent(s) can change dynamically

parent* ...

width 4

height 10

parent*

parent* ...

width 30

height 5

depth 12

18 / 22

Delegation: Flexibility (3)

▶ Objects can have unique or shared values for state variables

parent* ...

width 4

height 10

parent* parent*

width 9

height 32

19 / 22

Inheritance vs. DelegationInheritance

▶ Objects of the same class have the same behaviour▶ Objects have unique values for state variables▶ Object structure and behaviour is fixed at compile-time▶ The class of an object is fixed

Delegation▶ Objects built from same prototype can differ in their behaviour▶ Objects can have unique or shared values for state variables▶ Objects can dynamically change (add, remove) operations and

state variables▶ Object’s parent(s) change can change dynamically

⇒ Delegation is more flexible than inheritance. Is this added flexibilityhelpful or harmful?

20 / 22

Class-based vs. Prototype-based Languages

Class-based▶ Classes describe how objects behave▶ Good for situations where many objects have same behaviour

(one class – many instances)▶ Extra effort to create singleton objects

Prototype-based▶ Objects embody description of their own behaviour▶ Good for situations where many objects have unique behaviour▶ “Singleton” objects are easy

21 / 22

This Week’s Reading Assignment

▶ David Ungar, Craig Chambers, Bay-Wei Chang, and Urs Hölzle,Organizing Programs Without Classes, Lisp and SymbolicComputation 4(3), Kluwer Academic Publishers, June, 1991.

▶ Download link:http://bibliography.selflanguage.org/organizing-programs.html

22 / 22