Multi-Methods in Cecil

1. Multi-Methods in Cecil Objects and Aspects (Fall 2004) September 20, 2004 Kevin Bierhoff

2. Agenda • Generic functions • Cecil • Object model • Method dispatch • Encapsulation • Open questions Discussion any time Objects and Aspects: Multi-Methods in Cecil

3. Generic functions allow dynamic dispatch on multiple arguments • Define the generic function add(a, b) with • add(Integer a, Integer b) • add(Integer a, Double b) • add(Double a, Integer b) • add(Double a, Double b) • Which method receives add(x, y) ? • Depends on runtime type of x and y • Java’s x.add(y) would only look at x! Objects and Aspects: Multi-Methods in Cecil

4. Generic functions can be simulated in object-oriented languages … • class Object • boolean equals(Object other) • return other.equalsOther(this) • boolean equalsOriginal(Object original) • return this == original • class Point extends Object • protected int x, y; • boolean equalsOriginal(Point original) • return x == original.x && y == original.y; “DoubleDispatch” Objects and Aspects: Multi-Methods in Cecil

5. … but it’s a real pain • class Point [cont.] • boolean equals(Object other) • return other.equalsOther(this) • class ShadowPoint extends Point • boolean equals(Object other) • return other.equalsOther(this) • boolean equalsOriginal(Point original) • return x == (original.x – 5) && y == (original.y – 5) • boolean equalsOriginal(ShadowPoint original) • return x == original.x && y == original.y • class Point [cont.] • boolean equalsOriginal(ShadowPoint original) • return x == (original.x + 5) && y == (original.y + 5) Static binding Consistent behavior Code both sides Behavior for new classes cannot be added later Objects and Aspects: Multi-Methods in Cecil

6. Generic functions as in CLOS foster functional programming • Generic functions are external to objects • Leave only data fields within the objects • Implicit generic functions for accessor methods • Prohibit data encapsulation • Incredibly complex inheritance rules • To resolve dispatch ambiguities (cf.) • Really not transparent to programmer Objects are really structs Cecil addresses both problems mentioned here Objects and Aspects: Multi-Methods in Cecil

7. Cecil builds its object model on Self • Object model based on prototypes • Supports multiple inheritance • Root object called “any” • Adds or modifies several ideas • Inheritance vs. subtyping of objects • Abstract, template, and unique objects • Local vs. shared fields and their accessors Objects and Aspects: Multi-Methods in Cecil

8. Cecil distinguishes inheritance and subtyping of objects • Adopt behavior through inheritance • int = object inherits number • Override methods to adapt behavior • Get new concrete object at runtime • var ::= object inherits int • Adopt interface through subtyping • type collection • type list subtypes collection • set = object inherits array subtypes collection Inheritance crucial for method dispatch Objects and Aspects: Multi-Methods in Cecil

9. Cecil can enforce special roles of objects at runtime • abstract objects are not completely defined • Can contain abstract methods • Similar to abstract classes in Java • template objects for concrete incarnations • Cannot be manipulated at runtime • int = template object inherits number • var ::= object inherits int • int.set_value(5) -- is invalid • unique objects exist exactly once • zero = unique object inherits number • var ::= object inherits zero -- is invalid Objects and Aspects: Multi-Methods in Cecil

10. Objects can have state • Define data fields for objects • value(n@number) { field } • By default fields are local to an object • Can also be shared between objects • Each field implicitly defines pair of accessors • Get with value(num), set it with set_value(num, 5) • Fields can be declared read-only / init-only • var ::= object inherits int [value := 5] -- for initialization • Note: Self shares fields on inheritance • Thus usually need a “traits” object with behavior and an inheriting “template” that holds fields and is cloned • This separation is not necessary in Cecil Objects and Aspects: Multi-Methods in Cecil

11. Cecil associates multi-methods with all objects involved • Constrained arguments for multi-methods • Dynamic dispatch on all constrained arguments • OOP as special case • No constrained argument  static function • One constrained argument  ~ OOP (Single-Dispatch) • Two or more constrained arguments  Multi-Dispatch • Multi-methods belong to all constrained args • Code is now best viewed as a graph int + int int + double int double double + int double + double Objects and Aspects: Multi-Methods in Cecil

12. Constrain arguments with @ • Template objects • int = template object inherits number • double = template object inherits number • Methods • a@int + b@int { … } • a@int + b@double { … } • a@double + b@int { … } • a@double + b@double { … } Objects and Aspects: Multi-Methods in Cecil

13. Multi-methods provoke ambiguities similar to multiple inheritance … • “Diamond” relationships collection contains(c@collection, elem) unsorted_list sorted_list contains(c@unsorted_list, elem) contains(c@sorted_list, elem) set Now what happens if you call “contains” with a set? Objects and Aspects: Multi-Methods in Cecil

14. … as well as new ambiguities related to multiple dispatch collection merge(c1@collection, c2@collection) sorted_list merge(s1@sorted_list, c2@collection) merge(c1@collection, s2@sorted_list) Now what happens if you call “merge” with two sorted_list objects? Objects and Aspects: Multi-Methods in Cecil

15. Cecil leaves these ambiguities to the programmer • Cecil’s dispatch mechanism • Find syntactically fitting methods • Ignore those with a too specialized argument • Find the most specialized under the remaining • Ambiguity  runtime exception • Programmer must resolve manually • Note: CLOS avoids ambiguities • By totally ordering all methods Objects and Aspects: Multi-Methods in Cecil

16. Cecil allows information hiding … • Fields and methods can be private • Really means protected • Access based on caller privileges • Analyze signature of calling method • Match calling to requested objects • Grant access to all super- and sub-objects draw(s@shape) { if(has_changed(s), { draw_shape(s) }, { } ) } draw(v@visible) { draw_shape(v) } visible draw(v@visible) What isthe difference toOO? draw(s@shape) shape private draw_shape(s@shape) x y size_x size_y rectange private draw_shape(s@shape) Objects and Aspects: Multi-Methods in Cecil

17. … but tolerates serious encapsulation breaches • Want to break into an object? • Just define a new method that takes this object as a constrained argument • breach(a@rectangle) { access private fields now } • breach(a@any) { access whatever you want } Is that good or evil? Objects and Aspects: Multi-Methods in Cecil

18. CLOS Generic functions External to object hierarchy Foster functional programming approach Fails to address object encapsulation Cecil Multi-methods Belong to all dynamic arguments Graph-based object-oriented programming Offers (some) encapsulation Cecil solves issues in CLOS … Objects and Aspects: Multi-Methods in Cecil

19. … but raises new questions • Do you like • the object model better than Self’s? • how Cecil (does not re)solve ambiguities? • that methods belong to multiple objects? • Hey, where is the code hierarchy? • Is this really better than double dispatch? • Does this really feel • like (multi-) object-oriented programming? Objects and Aspects: Multi-Methods in Cecil