Chair of Software Engineering ATOT - Lecture 24, 25 June Advanced Topics in Object Technology Bertrand Meyer

Chair of Software Engineering ATOT - Lecture 24, 25 June Lecture 24: Agents and event-driven design

Chair of Software Engineering ATOT - Lecture 24, 25 June Avoiding glue code Event producer (e.g. GUI) Business model (application logic) Connection object Direct subscription

Chair of Software Engineering ATOT - Lecture 24, 25 June Metrics example create source_line_metric.make (“Source_lines”, [ [feature_scope, agent feature_line_counter], [class_scope, agent class_line_counter] ] )

Chair of Software Engineering ATOT - Lecture 24, 25 June Error handling example: without agents action1 if ok1 then action2 if ok2 then action3... More processing, more nesting... end

Chair of Software Engineering ATOT - Lecture 24, 25 June Error handling: with agents execute ([agent action1, agent action2 (...), agent action3 (...)]) if glitch then warning (glitch_message) end

Chair of Software Engineering ATOT - Lecture 24, 25 June Normal call vs. agent  Normal call a0.f (a1, a2, a3)  Agent call (expression): preface it by keyword agent, yielding agent a0.f (a1, a2, a3)  For example: u := agent a0.f (a1, a2, a3)  This represents the routine, ready to be called. To call it: u.call ([]) -- For type of u, see next  Recall original name of agents: “delayed calls”.

Chair of Software Engineering ATOT - Lecture 24, 25 June Type of closed agent expression  In class C: f (x1: T1; x2: T2; x3: T3) is do... end u := agent f (a1, a2, a3)  In some other class: a0: C v := agent a0.f (a1, a2, a3)  Type of both u and v: u, v: PROCEDURE [C, TUPLE]

Chair of Software Engineering ATOT - Lecture 24, 25 June Tuples  Purposes:  Allow manipulation of sequences of values with arbitrary number of elements, with simple structure  Support “anonymous classes”  To allow for function that return multiple results  Permit type-safe agents

Chair of Software Engineering ATOT - Lecture 24, 25 June Tuple classes  Syntax: TUPLE [X, Y, …] TUPLE TUPLE [A] TUPLE [A, B]

Chair of Software Engineering ATOT - Lecture 24, 25 June Mathematical model for tuples  First intuition: TUPLE [A, B, C] represents the cartesian product A x B x C  But: A x B x C cannot be mapped to a subset of A x B !  Better model:  TUPLE represents the set of partial functions from N (set of integers) to the set of possible values, whose domain includes the interval [1.. n] for some n.  Example of such a function: {,, }  An element of TUPLE [A, B, C] is a function whose domain includes the interval [1.. 3])  So it’s also an element of TUPLE [A, B]: functions whose domain includes interval [1.. 2].

Chair of Software Engineering ATOT - Lecture 24, 25 June Reminder: constrained genericity  LIST [G] (unconstrained): G represents arbitrary type. May use LIST [INTEGER] LIST [EMPLOYEE] LIST [SHIP]  SORTABLE_LIST [G -> COMPARABLE] (constrained by COMPARABLE)  G represents type descending from COMPARABLE LIST [INTEGER] LIST [T] only if T descendant of COMPARABLE

Chair of Software Engineering ATOT - Lecture 24, 25 June Agent types: Kernel library classes ROUTINE* [BASE, ARGS -> TUPLE] PROCEDURE* [BASE, ARGS -> TUPLE] FUNCTION* [BASE, ARGS -> TUPLE, RES] call item Inherits from * Deferred

Chair of Software Engineering ATOT - Lecture 24, 25 June Features of routine classes call (values: ARGS) item (values: ARGS): RES -- In FUNCTION only... target, arguments, set_target, set_arguments...  Introspection features (in progress): precondition: FUNCTION [BASE, ARGUMENTS, BOOLEAN] postcondition type: TYPE Features of class TYPE: heirs, parents, routines etc.

Chair of Software Engineering ATOT - Lecture 24, 25 June Keeping arguments open  An agent can have both “closed” and “open” arguments.  Closed arguments set at time of agent definition; open arguments set at time of each call.  To keep an argument open, just replace it by a question mark: u := agent a0.f (a1, a2, a3) -- All closed (as before) w := agent a0.f (a1, a2, ?) x := agent a0.f (a1, ?, a3) y :=agent a0.f (a1, ?, ?) z :=agent a0.f (?, ?, ?)

Chair of Software Engineering ATOT - Lecture 24, 25 June Agent types  Reminder: PROCEDURE [BASE, ARGS –> TUPLE] f (x1: T1; x2: T2; x3: T3) is -- in class C do... end agent a0.f (a1, a2, a3)PROCEDURE [C, TUPLE] -- All closed agent a0.f (a1, a2, ?)PROCEDURE [C, TUPLE [T3]] agent a0.f (a1, ?, a3)PROCEDURE [C, TUPLE [T2]] agent a0.f (a1, ?, ?) PROCEDURE [C, TUPLE [T2, T3]] agent a0.f (?, ?, ?)PROCEDURE [C, TUPLE [T1, T2, T3]]

Chair of Software Engineering ATOT - Lecture 24, 25 June Calling an agent a0: C; a1: T1; a2: T2; a3: T3 u :=agent a0.f (a1, a2, a3)PROCEDURE [C, TUPLE] u.call ([]) v := agent a0.f (a1, a2, ?)PROCEDURE [C, TUPLE [T3]] v.call ([a3]) w := agent a0.f (a1, ?, a3)PROCEDURE [C, TUPLE [T2]] w.call ([a2]) x := agent a0.f (a1, ?, ?)PROCEDURE [C, TUPLE [T2, T3]] x.call ([a2, a3]) y := agent a0.f (?, ?, ?)PROCEDURE [C, TUPLE [T1, T2, T3]] y.call ([a1, a2, a3])

Chair of Software Engineering ATOT - Lecture 24, 25 June Keeping the target open r := agent {T0}.f (a1, a2, a3) -- Target open, arguments closed Type is: PROCEDURE [T0, TUPLE [T0]] Example call: r.call ([a0]) s := agent {T0}.f (?, ?, ?) -- Open on all operands -- Can also be written as just: agent {T0}.f Type is: PROCEDURE [T0, TUPLE [T0, T1, T2, T3]] Example call: s.call ([a0, a1, a2, a3])

Chair of Software Engineering ATOT - Lecture 24, 25 June Calling an agent: integration example b  my_function (x) dx a b  your_function (x, u, v) dx a my_integrator.integral (agent my_function, a, b) my_integrator.integral (agent your_function (?, u, v), a, b)

Chair of Software Engineering ATOT - Lecture 24, 25 June The integral function integral (f: FUNCTION [ANY, TUPLE [REAL], REAL]; low, high: REAL): REAL is -- Integral of f over the interval [low, high] local x: REAL i: INTEGER do from x := low until x > high loop Result := Result + f.item ([x]) * step i := i + 1 x := x + i * step end

Chair of Software Engineering ATOT - Lecture 24, 25 June Calling an agent: iterator all_positive := my_integer_list.for_all (agent is_positive (?)) all_married := my_employee_list.for_all (agent {EMPLOYEE}.is_married)

Chair of Software Engineering ATOT - Lecture 24, 25 June Iterators  In class LINEAR [G], ancestor to all classes representing lists, sequences etc. for_all (test: FUNCTION [ANY, TUPLE [G], BOOLEAN]) is -- Is there no item in structure that doesn’t -- satisfy test? do from start Result := True until off or not Result loop Result := test.item ([item]) forth end end

Chair of Software Engineering ATOT - Lecture 24, 25 June Iterators (cont’d) for_all there_exists do_all do_if do_while do_until

Chair of Software Engineering ATOT - Lecture 24, 25 June Command classes  Undo-redo design pattern  Support for undo, redo  Class COMMAND provides a procedure execute and its heir UNDOABLE_COMMAND adds undo.  Write a new class for every kind of undoable command.

Chair of Software Engineering ATOT - Lecture 24, 25 June Command classes (cont’d)  Traditionally: one command class (descendant of COMMAND) for every kind of command.  Now, can transform any procedure into command: operation: PROCEDURE [CONTEXT, TUPLE] -- Operation to be applied by current command make (p: like operation) is -- Make p the current command’s operation. require p_not_void: p /= Void do operation := p ensure operation_set: operation = p end

Chair of Software Engineering ATOT - Lecture 24, 25 June Inline agents (under discussion) my_employee_list.do_all (do count := count + 1 end)

Chair of Software Engineering ATOT - Lecture 24, 25 June Lessons: On language design & evolution  Maximize Signal Noise  Provide one good way to do anything  Dogmatism / Consistency?

Chair of Software Engineering ATOT - Lecture 24, 25 June Extensions (Eiffel: The Language, 1991) “There is one and only one kind of acceptable language extension: the one that dawns on you with the sudden self-evidence of morning mist. It must provide a complete solution to a real problem, but usually that is not enough: almost all good extensions solve several potential problems at once, through a simple addition. It must be simple, elegant, explainable to any competent user of the language in a minute or two. It must fit perfectly within the spirit and letter of the rest of the language. It must not have any dark sides or raise any unanswerable questions. And because software engineering is engineering, you must see the implementation technique.”

Chair of Software Engineering ATOT - Lecture 24, 25 June Is this a new programming paradigm?  Lack of a methodology

Chair of Software Engineering ATOT - Lecture 24, 25 June End of lecture 24