From e0e94e503094c48d826c0558f56418a50717e558 Mon Sep 17 00:00:00 2001 From: eiffel-org Date: Sat, 14 Oct 2017 13:11:12 +0000 Subject: [PATCH] Update wikipage Event Programming with Agents. (Signed-off-by:bmeyer). git-svn-id: https://svn.eiffel.com/eiffel-org/trunk@1921 abb3cda0-5349-4a8f-a601-0c33ac3a8c38 --- .../eiffel-net/event-programming-agents.wiki | 18 +++++++++--------- 1 file changed, 9 insertions(+), 9 deletions(-) diff --git a/documentation/17.05/solutions/platform-specifics/microsoft-windows/net/eiffel-net-language/eiffel-net/event-programming-agents.wiki b/documentation/17.05/solutions/platform-specifics/microsoft-windows/net/eiffel-net-language/eiffel-net/event-programming-agents.wiki index d108125d..e721a5cd 100644 --- a/documentation/17.05/solutions/platform-specifics/microsoft-windows/net/eiffel-net-language/eiffel-net/event-programming-agents.wiki +++ b/documentation/17.05/solutions/platform-specifics/microsoft-windows/net/eiffel-net-language/eiffel-net/event-programming-agents.wiki @@ -9,11 +9,11 @@ The implementation of agents is an advanced topic, but you do not have to unders Object technology is based on the idea that when we model systems based on objects, representing the "things" they manipulate. As to operations on these objects, they appear in the corresponding classes, as routines (functions and procedures). Operations are not objects. -Sometimes, on the other hand, the "things" we model with our objects could represent operations. For example, We do this in the same fashion that we model other concepts: statically as classes, and as objects at runtime. +Sometimes, on the other hand, the "things" we model with our objects could represent operations. For example, we might want to build a list of tasks to be performed later; each task is defined by a routine. Each of the objects in the list will represent the corresponding routine. -An object that represents an operation is called an agent. +Such an object, representing an operation, is called an agent. -If we can have a runtime object that represents an operation, then we can place the object in the structure of another object, where at some later time, a client can cause the associated operation to execute. +If we can have a run-time object that represents an operation, then we can place the object in the structure of another object, where at some later time, a client can cause the associated operation to execute. This is a very desirable model for event driven processing, like graphical user interfaces. The operations that are executed when a user take some action like clicking on a button, could be represented by agents. When the user interface element is initialized, agents that represent the action routines are stored within the interface element. Then at the time that an event, say a button click, occurs, the agents for that event are retrieved and their associated operations are executed. @@ -23,9 +23,9 @@ Another area in which agents are commonly used is in traversing data structures. We know that there are two types of routines in Eiffel, functions and procedures. -Not surprisingly, the implementation of agents relies on three classes in the Base Library. Class ROUTINE, and its heirs FUNCTION and PROCEDURE. +The implementation of agents correspondingly relies on three classes in the Base Library: class ROUTINE for the general notion, and its heirs FUNCTION, with and PROCEDURE. In addition, PREDICATE, an heir of FUNCTION , covers the particular case of a function returning a boolean result. -When you use an agent from a client routine, you will be building an instance of either FUNCTION or ROUTINE. This happens implicitly as you will see. +When you use an agent from a client routine, you will be building an instance of either FUNCTION or ROUTINE. ==Using Agents== @@ -42,10 +42,10 @@ It is important to understand that step_forward does not get applie In this example, the routine "step_forward" on which the agent is based takes no arguments. If you drilled down into the workings of this example you would find that class that implements the feature extend is class EV_NOTIFY_ACTION_SEQUENCE. You would also see that the signature for the feature extend is as essentially as follows. - extend (v: PROCEDURE [ANY, TUPLE]) + extend (v: PROCEDURE [TUPLE]) -We don't have to know too much about the workings of agents to see that "extend" takes an argument v which is of type PROCEDURE. It turns out that the actual generic parameter TUPLE represents the set of "open" arguments. In this case, extend is expecting an agent which has no open arguments. +We don't have to know too much about the workings of agents to see that "extend" takes an argument v which is of type PROCEDURE. The actual generic parameter TUPLE represents the set of "open" arguments. In this case, extend is expecting an agent with no open arguments. ===Open and Closed Arguments=== @@ -53,7 +53,7 @@ It is this business of open and closed arguments which really makes agents remar Suppose a class has a feature declared as shown below. - my_procedure: PROCEDURE [ANY, TUPLE] + my_procedure: PROCEDURE [TUPLE] Then what can be assigned to my_procedure?. An agent, of course. Say the class has procedures as follows. @@ -83,7 +83,7 @@ Now let's turn our attention to the other procedure two_argument_procedure my_procedure := agent two_argument_procedure (1, 2) -- Is Valid -What happens here is that values are fixed for those arguments at the time that the agent, an object of type PROCEDURE [ ANY, TUPLE] is created. +What happens here is that values are fixed for those arguments at the time that the agent, an object of type PROCEDURE [ TUPLE] is created. So this is the wonderful thing about agents. A routine which will be represented as an agent does not have to be an exact fit for the expected signature. By closing some arguments at agent creation, you have effectively produced a new and conforming routine.