Difference between revisions of "Agent"
Jump to navigation
Jump to search
Line 1: | Line 1: | ||
+ | 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. |
||
− | Agents are objects that allow to defer computation. |
||
+ | See http://www.jot.fm/issues/issue_2004_04/article7/ |
||
− | (to be completed) |
||
+ | (to be completed) |
||
Revision as of 11:54, 20 November 2013
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.
See http://www.jot.fm/issues/issue_2004_04/article7/
(to be completed)
Inline agents
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)