Difference between revisions of "Agent"
Hzwakenberg (talk | contribs) m (→Overview) |
Hzwakenberg (talk | contribs) m |
||
Line 5: | Line 5: | ||
The agent mechanism gives the Eiffel object-oriented language the ability to handle operations, or commands, as such, like in functional programming languages. |
The agent mechanism gives the Eiffel object-oriented language the ability to handle operations, or commands, as such, like in functional programming languages. |
||
− | Agents are a new type of objects that allow to store code to be executed |
+ | Agents are a new type of objects that allow to store the code to be executed together with its data into an object, named the agent. In Eiffel, four types of agents exist: a deferred type [[library_class:ROUTINE|<tt>ROUTINE</tt>]], and three concrete types [[library_class:PROCEDURE|<tt>PROCEDURE</tt>]], [[library_class:FUNCTION|<tt>FUNCTION</tt>]] and [[library_class:PREDICATE|<tt>PREDICATE</tt>]]. |
The following figure shows their inheritance relationship: |
The following figure shows their inheritance relationship: |
Revision as of 10:58, 17 June 2016
In Eiffel, the notion of agent makes it possible to describe and manipulate computation parts (i.e. operations) like ordinary data. Operations may be partially described, may be passed as ordinary data and may have their execution delayed. Agents are very convenient for many purposes, such as going through data structures and implementing call-backs in graphical libraries.
Overview
The agent mechanism gives the Eiffel object-oriented language the ability to handle operations, or commands, as such, like in functional programming languages.
Agents are a new type of objects that allow to store the code to be executed together with its data into an object, named the agent. In Eiffel, four types of agents exist: a deferred type ROUTINE, and three concrete types PROCEDURE, FUNCTION and PREDICATE.
The following figure shows their inheritance relationship:
Agents are a way of storing operations for later execution. They are objects. As such, they can be stored, compared to Void, or passed around to other software components. The operation stored in the agent may then be executed whenever the component decides to do so. The most common uses of agents are delayed calls, multiple calls (on different values), lazy evaluation, and so on.
Conformance rules
The ROUTINE types are generic types with more semantic. As ROUTINE types do not have their own conformance rules one may think that the generic types rules apply. We will hold true this assumption in this chapter, and show that we can make dogs eat tomatoes.
The ROUTINE type is a generic type with one formal type parameter: ROUTINE[OPEN -> TUPLE]. A type ROUTINE[O1] conforms to a type ROUTINE[O2] only if O2 conforms to O1.
The PROCEDURE type inherits from ROUTINE, and has the same formal type parameter: PROCEDURE[OPEN –> TUPLE]. Its conformance rule is thus the same as for ROUTINE.
The FUNCTION type inherits from ROUTINE, and has two formal type parameters: FUNCTION[OPEN –> TUPLE, RESULT_TYPE]. According to the conformance rule for generic types, a type FUNCTION[O1, R1] conforms to a type FUNCTION[O2, R2] only if O2 conforms to O1 and R1 conforms to R2.
PREDICATE[O] type being just a shortcut for FUNCTION[O, BOOLEAN], and it has the same conformance rules as FUNCTION.
Note: You must be aware of the conformance inversion for the open arguments tuple. See http://www.jot.fm/issues/issue_2004_04/article7/ for the rationale.
Inline agents
> NB: The following will apply from the Bell release onwards. In Adler, inline agents are just anonymous features.
Inline agents are closures: they may access the arguments and local variables defined in their outside feature (called outside variables).
The usage limits are:
- names must be unique (i.e. shadowing an outside variable is not allowed)
- Result is not accessible to inline agents; one must use another local variable (rationale: if the agent is a function, what would Result refer to?)
- access is read-only: you cannot assign to an outside local variable (and, of course, to an argument, but that's standard Eiffel anyway)
The technical limits are:
- beware of automatically allocated pointers for outside local variables, especially if the GC is not used. There is no such problem for arguments since their value cannot change throughout the execution of the outside feature
- expanded arguments are twinned in the inline agent context (of course)