- 8 - Event-Driven programming, agents & tuples

1. - 8 - Event-Driven programming, agents & tuples

2. Our goal for this session • Extend our control structures with a more flexible mechanism, supporting in particular the needs of interactive, graphical programming (GUI) • The resulting mechanism, agents, has many other exciting applications • Other languages have facilities such as delegates (C#), closures (functional languages)

3. Handling input through traditional techniques • Program drives user: • from • i:= 0 • read_line • untilend_of_fileloop • i:=i+ 1 • Result [i] :=last_line • read_line • end

4. Handling input with modern GUIs • User drives program: “When a user presses this button, execute that action from my program”

5. CLICK START STATION ABOVE Event-driven programming: an example • Specify that when a user clicks this button the system must execute • find_station(x, y) • where x and yare the mouse coordinates andfind_stationis a specific procedure of your system.

6. Some issues • 1. Keeping the “business model” and the GUI separate • Business model (or just model): core functionality of the application • GUI: interaction with users • 2. Minimizing “glue code” between the two • 3. Making sure we keep track of what’s going on

7. Event-driven programming: a metaphor Subscribers Publishers Routine Routine Routine Routine Routine Routine Routine

8. Observing a value VIEW Observers A = 50%B = 30%C = 20% Subject

9. Model-View Controller(TrygveReenskaug, 1979)

10. CLICK START STATION ABOVE Our example • Specify that when a user clicks this button the system must execute • find_station(x, y) • where x and yare the mouse coordinates andfind_stationis a specific procedure of your system.

11. Alternative terminologies • Observed / Observer • Subject / Observer • Publish / Subscribe • Event-driven design/programming In this presentation: Publisher and Subscriber

12. A solution: the Observer Pattern publish + attach *SUBSCRIBER *PUBLISHER detach update* subscribe+ subscribed: LIST […] unsubscribe+ … … +PUB1 +PUB2 +SUB2 +SUB1 update+ update+ Inherits from * Deferred (abstract) + Effective (implemented) Client (uses)

13. Design patterns • A design pattern is an architectural scheme — a certain organization of classes and features — that provides applications with a standardized solution to a common problem. • Since 1994, various books have catalogued important patterns. Best known is Design Patterns by Erich Gamma, Richard Helm, Ralph Johnson, John Vlissides, Addison-Wesley 1994

14. A solution: the Observer Pattern publish + attach *SUBSCRIBER *PUBLISHER detach update* subscribe+ subscribed: LIST […] unsubscribe+ +PUB1 +SUB1 update+ Inherits from * Deferred (abstract) + Effective (implemented) Client (uses)

15. s2 s1 s3 s4 Observer pattern • Publisher keeps a (secret) list of observers: • subscribed : LINKED_LIST [SUBSCRIBER] • To register itself, • an observer executes • subscribe (some_publisher) • wheresubscribeis defined in SUBSCRIBER: • subscribe (p: PUBLISHER) • -- Make current object observep. • dop.attach (Current) • end

16. Attaching an observer • In classPUBLISHER: • feature{SUBSCRIBER} • attach (s: SUBSCRIBER) • -- Registersas subscriber to this publisher. • require • subscriber_exists: s /= Void • do • subscribed.extend(s) • end • Note that the invariant ofPUBLISHERincludes the clause • subscribed /= Void • (Listsubscribedis created by creation procedures of PUBLISHER) Why?

17. s1 s2 s3 s4 Triggering an event attach publish+ *SUBSCRIBER detach • publish • -- Ask all observers to -- react to current event. • dofrom • subscribed.start • until • subscribed.after • loop • subscribed.item. • subscribed.forth • endend • Each descendant of OBSERVER defines its own version of update *PUBLISHER subscribed update* +PUB1 +SUB1 update+ Dynamic binding update after item sub subscribed forth Cursor

18. Observer pattern (in basic form) • Publishers know about subscribers • Handling arguments is messy • Not reusable — must be coded anew for each application

19. Another approach: event-context-action table • Set of triples • [Event type, Context, Action] Event type: any kind of event we track Example: left mouse click Context: object for which these events are interestingExample: a particular button Action: what we want to do when an event occurs in the contextExample: save the file Event-context-action table may be implemented as e.g. a hash table

20. Event-context-action table • More precisely: Event_type – Action Table More precisely: Event_type - Context – Action Table Eventtype Context Action Save_button Save_file Left_click Reset Cancel_button Left_click Find_station Map Left_click Left_click … … … Right_click Display_Menu … …

21. CLICK START STATION ABOVE Event-action-context table • Set of triples • [Event, Context, Action] Event: any occurrence we trackExample: a left click Context: object for which the event is interestingExample: the map widget Action: what we want to do when the event occurs in contextExample: find the station closest to coordinates Action-event table may have various implementations, e.g. hash table.

22. CLICK START STATION ABOVE In EiffelVision • Paris_map.click.action_list.extend (agentfind_station)

23. Mechanisms in other languages • C and C++: “function pointers” • C#: delegates (more limited form of agents)

24. Language note • In non-O-O languages, e.g. C and Matlab, there is no notion of agent, but you can pass a routine as argument to another routine, as in • integral (& f, a, b) • wherefis the function to integrate.& f(C notation, one among many possible ones) is a way to refer to the functionf. (We need some such syntax because just `f’ could be a function call.) • Agents (or delegates in C#) provide a higher-level, more abstract and safer technique by wrapping the routine into an object with all the associated properties.

25. A little language quiz • What does this do? • f: INTEGER • do • Result:= g (f) • end • g (x: INTEGER): INTEGER • do • Result := x • end

26. Using the Eiffel Event Library Event: each event type will be an objectExample: left click Context: an object, usually representing a user interface elementExample: the map Action: an agent representing a routine Example: find_station

27. The Event library • Basis: • One generic class:ACTION_SEQUENCE • Two features: putandcall • For example: A map widgetParis_mapthat reacts in a way defined in find_stationwhen clicked (event left_click):

28. Example using the Event library • The publisher (“subject”) creates an action sequence object: • left_click: ACTION_SEQUENCE [TUPLE[INTEGER, INTEGER]] • -- Left mouse click events • once • createResult • ensure • exists: Result /= Void • end • The publisher triggers the event: • left_click.call([x_positition, y_position]) • The subscribers (“observers”) subscribe to events: • Paris_map.left_click.put(agentfind_station) find_station (x: INTEGER; y: INTEGER)

29. Observer pattern vs. Event Library • In case of an existing classMY_CLASS: • With the Observer pattern: • Need to write a descendant ofSUBSCRIBER and MY_CLASS • Useless multiplication of classes • With the Event Library: • Can reuse the existing routines directly as agents

30. Subscriber variants • click.put(agentfind_station) • click.put(agentfind_station) • click.put(agent ) • click.put(agentother_object.other_procedure) Paris_map. your_procedure(a, ?, ?, b)

31. Tuples • Tuple types (for any typesA, B, C, ... ): • TUPLE TUPLE [A] TUPLE [A, B] TUPLE [A, B, C] • ... • A tuple of typeTUPLE [A, B, C] is a sequence of at least three values, first of typeA, second of typeB, third of typeC. • Tuple values: e.g. • [a1, b1, c1, d1]

32. Tuple type inheritance TUPLE TUPLE [A] TUPLE [A, B] …

33. Labeled tuple types • TUPLE [author: STRING; year: INTEGER; title: STRING] • Restricted form of class • A labeled tuple type denotes the the same type as unlabeled form, here • TUPLE [STRING, INTEGER, STRING] • but facilitates access to individual elements • To denote a particular tuple (labeled or not): • [”Tolstoy”,1865, ”War and Peace”] • To access tuple elements: use e.g.t.year

34. What you can do with an agent a • Call the associated routine through the feature call, whose argument is a single tuple: • a.call( [horizontal_position, vertical_position] ) • If a is associated with a function, a.item ([ ..., ...]) gives the result of applying the function. A manifest tuple

35. Tuples: Procedures vs. Functions • Features applicable to an agent a: • Ifarepresents a procedure,a.call ([argument_tuple])calls the procedure • If a represents a function,a.item ([argument_tuple])calls the function and returns its result

36. Example using the Event library • The publisher (“subject”) creates an action sequence object: • left_click: ACTION_SEQUENCE [TUPLE[INTEGER, INTEGER]] • -- Left mouse click events • once • createResult • ensure • exists: Result /= Void • end • The publisher triggers the event: • left_click.publish ([x_positition, y_position]) • The subscribers (“observers”) subscribe to events: • Paris_map.left_click.subscribe (agentfind_station)

37. What you can do with an agent a • Call the associated routine through the feature call, whose argument is a single tuple: • a.call( [horizontal_position, vertical_position] ) • If a is associated with a function, a.item ([ ..., ...]) gives the result of applying the function. A manifest tuple

38. 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 := agenta0.f (a1, a2, a3) -- All closed (as before) • w := agenta0.f (a1, a2, ? ) • x := agenta0.f (a1, ? , a3) • y := agenta0.f (a1, ?, ? ) • z := agenta0.f (?, ?, ? )

39. Calling the agent f (x1: T1 ; x2: T2 ; x3: T3) a0: C ; a1: T1 ; a2: T2 ; a3: T3 u := agenta0.f(a1, a2, a3) v := agenta0.f (a1, a2, ?) w := agenta0.f (a1, ? , a3) x := agenta0.f (a1, ?, ?) y := agenta0.f (?, ?, ?) u.call ([]) v.call([a3]) w.call([a2]) x.call([a2, a3]) y.call([a1, a2, a3])

40. Another example of using agents b  my_function(x)dx a b  your_function(x, u, v)dx a my_integrator.integral( agentmy_function, a, b) my_integrator.integral(agentyour_function(?, u, v), a, b)

41. a b The integration function f • integral ( : FUNCTION [ANY, TUPLE [REAL], REAL]; a, b:REAL):REAL-- Integral offover interval[a, b]localx: REAL; i: INTEGERdofromx := a untilx > b loopResult := Result +   stepi := i + 1 x := a + istep • end • end f.item([x])

42. Another application: using an iterator • class C feature • all_positive, all_married: BOOLEAN • is_positive (n: INTEGER) : BOOLEAN • -- Isngreater than zero? • doResult := (n > 0) end • intlist: LIST [INTEGER] • emplist: LIST [EMPLOYEE] • r • do • all_positive:=intlist.for_all(agentis_positive (?) ) • all_married:=emplist.for_all(agent{EMPLOYEE}is_married) • end • end classEMPLOYEEfeature is_married: BOOLEAN … end

43. Reminder: using inline agents intlist.for_all (agent (x: INTEGER): BOOLEAN do Result:= (x > 0) end)

44. Iterators • In classLINEAR [G], ancestor to all classes for lists, sequences etc., you will find: • for_all • there_exists • do_all • do_if • do_while • do_until

45. Applications of agents • Patterns: Observer, Visitor, Undo-redo (command) • Iteration • High-level contracts • Numerical programming • Introspection (finding out properties of the program itself)

46. Kernel library classes representing agents *ROUTINE call + + FUNCTION PROCEDURE last_result item + PREDICATE

47. Declaring an agent • p: PROCEDURE [ANY, TUPLE] • -- Agent representing a procedure, -- no open arguments • q: PROCEDURE [ANY, TUPLE [X, Y, Z]] • -- Agent representing a procedure, -- 3 open arguments • f: FUNCTION [ANY, TUPLE [X, Y, Z], RES] • -- Agent representing a procedure, -- 3 open arguments, result of typeRES

48. Calling an agent f (x1: T1 ; x2: T2 ; x3: T3) a0: C ; a1: T1 ; a2: T2 ; a3: T3 u := agenta0.f(a1, a2, a3) v := agenta0.f (a1, a2, ?) w := agenta0.f (a1, ? , a3) x := agenta0.f (a1, ?, ?) y := agenta0.f (?, ?, ?) u.call ([]) v.call([a3]) w.call([a2]) x.call([a2, a3]) y.call([a1, a2, a3])

49. Agents: summary and conclusion • Treat routines (computation) as objects • An indispensable complement to basic O-O mechanisms