mirrors/eiffel-org
1
0
Fork 0
mirror of https://github.com/EiffelSoftware/eiffel-org.git synced 2025-12-06 23:02:28 +01:00
Code Issues Packages Projects Releases Wiki Activity

Author:halw

Browse Source 
Date:2008-12-18T21:38:10.000000Z


git-svn-id: https://svn.eiffel.com/eiffel-org/trunk@141 abb3cda0-5349-4a8f-a601-0c33ac3a8c38
This commit is contained in:
halw
2008-12-18 21:38:10 +00:00
parent c49d647159
commit aa6644170d
1 changed files with 54 additions and 54 deletions
Download Patch File Download Diff File Expand all files Collapse all files

18
documentation/current/platform-specifics/microsoft-windows/net/eiffel-net-language/eiffel-net/event-programming-agents.wiki
View File

@@ -58,13 +58,13 @@ Suppose a class has a feature declared as shown below.
Then what can be assigned to <code>my_procedure</code>?. An agent, of course. Say the class has procedures as follows. Then what can be assigned to <code>my_procedure</code>?. An agent, of course. Say the class has procedures as follows.
<code> <code>
no_argument_procedure is no_argument_procedure
-- A procedure with no arguments -- A procedure with no arguments
do do
print ("No argument here!%N") print ("No argument here!%N")
end end
two_argument_procedure (an_int: INTEGER; another_int: INTEGER) is two_argument_procedure (an_int: INTEGER; another_int: INTEGER)
-- A procedure with two arguments -- A procedure with two arguments
do do
print ("My arguments are: " + an_int.out + " and " + another_int.out + "%N") print ("My arguments are: " + an_int.out + " and " + another_int.out + "%N")
@@ -76,18 +76,18 @@ Then the following assignment is valid.
my_procedure := agent no_argument_procedure my_procedure := agent no_argument_procedure
</code> </code>
What this means is that the agent created and associated with the procedure <code>no_argument_procedure</code> must conform to the type <code>PROCEDURE</code> [ <code>ANY</code>, <code>TUPLE</code>]. The feature <code>my_procedure</code> (which is of type <code>PROCEDURE</code>) can be attached at runtime to an agent representing a procedure with no open arguments, which indeed is what <code>no_argument_procedure</code> is. What this means is that the agent created and associated with the procedure <code>no_argument_procedure</code> must conform to the type <code>PROCEDURE [ANY, TUPLE]</code>. The feature <code>my_procedure</code> (which is of type <code>PROCEDURE [ANY, TUPLE]</code>) can be attached at runtime to an agent representing a procedure with no open arguments, which indeed is what <code>no_argument_procedure</code> is.
Now let's turn our attention to the other procedure <code>two_argument_procedure</code>. You might think that because it takes two arguments, that you would not be able to build an agent from it which could be assigned to the attribute <code>my_procedure</code>. But you can do it by closing the two arguments at the time that the agent is created, as in the following. Now let's turn our attention to the other procedure <code>two_argument_procedure</code>. You might think that because it takes two arguments, that you would not be able to build an agent from it which could be assigned to the attribute <code>my_procedure</code>. But you can do it by closing the two arguments at the time that the agent is created, as in the following.
<code> <code>
my_procedure := agent two_argument_procedure (1, 2) -- Is Valid my_procedure := agent two_argument_procedure (1, 2) -- Is Valid
</code> </code>
What happens here is that values are fixed for those arguments at the time that the agent, an object of type <code>PROCEDURE</code> [ <code>ANY</code>, <code>TUPLE</code>] is created. What happens here is that values are fixed for those arguments at the time that the agent, an object of type <code>PROCEDURE [ ANY, TUPLE]</code> 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. 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.
The advantange of this is that you can sometimes avoid building specialized routines for the sole purpose of having a routine which conforms to the agent signature. The advantage of this is that you can sometimes avoid building specialized routines for the sole purpose of having a routine which conforms to the agent signature.
To leave an argument open, you hold its place with a question mark. If you intend for all arguments to be open, then you may make them all question marks, or leave off the arguments entirely. To leave an argument open, you hold its place with a question mark. If you intend for all arguments to be open, then you may make them all question marks, or leave off the arguments entirely.
<code> <code>
@@ -112,7 +112,7 @@ and some code to put some strings in <code>my_strings</code>:
Our class also has a feature called <code>print_on_new_line</code> which we created to print a string preceded by a new line character. Our class also has a feature called <code>print_on_new_line</code> which we created to print a string preceded by a new line character.
<code> <code>
print_on_new_line (s: STRING) is print_on_new_line (s: STRING)
-- Print `s' preceded by a new line -- Print `s' preceded by a new line
do do
print ("%N" + s) print ("%N" + s)
@@ -136,18 +136,18 @@ The availability of agents gives us new options. <code>LINKED_LIST</code> has a
do_all (action: PROCEDURE [ANY, TUPLE [G]]) do_all (action: PROCEDURE [ANY, TUPLE [G]])
</code> </code>
As an argument <code>do_all</code> takes an agent based on a procedure with one open argument which is the same type as the list items (in this class, <code>G</code> is the formal generic parameter representing the type of the items being stored). Then it traverses the list executing the routine associated with that agent and roviding the current list item to satisfy the open argument. As an argument <code>do_all</code> takes an agent based on a procedure with one open argument which is the same type as the list items (in this class, <code>G</code> is the formal generic parameter representing the type of the items being stored). Then it traverses the list executing the routine associated with that agent and uses the current list item to satisfy the open argument.
Instead of coding the loop shown above, we can code this instruction: Instead of coding the loop shown above, we can code this instruction:
<code> <code>
my_list.do_all (agent print_on_new_line (?)) my_list.do_all (agent print_on_new_line (?))
</code> </code>
we leave the argument to <code>print</code> open, and <code>do_all</code> will provide it as a reference to the current list item as it traverses the list. we leave open the argument required by <code>print</code>, and <code>do_all</code> will provide it as a reference to the current list item as it traverses the list.
===Targets for Agents' Routines=== ===Targets for Agents' Routines===
In Eiffel every routine must be applied against a target object. In our model for computation, <code>x</code>. <code>f</code> ( <code>a</code>, ...), <code>x</code> is the target of the application of feature <code>f</code>. In the case of an agent, the agent must account for objects for each of the arguments and an object for the target of the routine. In Eiffel every routine must be applied against a target object. In our model for computation, <code>x.f (a, ...)</code>, the <code>x</code> is the target of the application of feature <code>f</code>. In the case of an agent, the agent must account for objects for each of the arguments and an object for the target of the routine.
Let's identify the targets in the examples shown. First: Let's identify the targets in the examples shown. First:
<code> <code>