Agent problems - Revision history

Colin-adams: Corrected typo from B to C

2007-04-11T13:30:38Z

Corrected typo from B to C

Manus at 10:12, 11 April 2007

2007-04-11T10:12:22Z

Manus: added category

2007-02-22T16:44:37Z

added category

Konradm at 18:26, 21 November 2006

2006-11-21T18:26:36Z

Konradm at 21:50, 20 November 2006

2006-11-20T21:50:37Z

Konradm at 21:41, 20 November 2006

2006-11-20T21:41:36Z

Konradm at 20:35, 20 November 2006

2006-11-20T20:35:35Z

New page

The following feature expects as its formal argument an agent:

<code>[eiffel,N]
foo (f: FUNCTION [A, TUPLE [B], C])
</code>

By giving its formal argument a type, a feature specifies what it expects of the actual arguments. Feature foo expects the passed agent to:
* refer to a feature of a descendant of class A.
* have at least one open argument. The type of it needs to be a descendant of class B.
* refer to a feature with a return type that is a descendant of class B.

@@ Line 1: / Line 1: @@
 [[Category:ECMA]]
-{{Warning|'''Warning''': Article under development}}
+{{UnderConstruction}}
 The following feature expects as its formal argument an agent:

← Older revision		Revision as of 16:44, 22 February 2007
Line 1:		Line 1:
		+	[[Category:ECMA]]
	{{Warning\|'''Warning''': Article under development}}		{{Warning\|'''Warning''': Article under development}}

@@ Line 8: / Line 8: @@
        l_f: FUNCTION [A, TUPLE, C]
     do
        Result := l_f.item ([])
     end
@@ Line 16: / Line 17: @@
 * have at least one open argument. The type of it needs to be a descendant of class B.
 * refer to a feature with a return type that is a descendant of class B.
-At the same time feature foo gives almost no guarantees about how it will use agent f. It calls the agent without passing any arguments. This is not detected by the type system but will certainly end in runtime failures. This is a very unfortunate situation. The Eiffel agent mechanism is quite verbose, the user has to type in a lot of typing information. At the same time the type system gives the programmer no safety. So besides CAT-calls, this is the second type hole in the Eiffel type system.
+At the same time feature foo gives almost no guarantees about how it will use agent f. It calls the agent without passing any arguments. This is not detected by the type system but will certainly end in runtime failures. This is a very unfortunate situation. The Eiffel agent mechanism is quite verbose, the user has to type in a lot of typing information. At the same time the type system gives the programmer no safety.

@@ Line 1: / Line 1: @@
 The following feature expects as its formal argument an agent:
@@ Line 14: / Line 16: @@
 * have at least one open argument. The type of it needs to be a descendant of class B.
 * refer to a feature with a return type that is a descendant of class B.
-At the same time feature foo gives almost no guarantees about how it will use agent f. It calls the agent without passing any arguments. This is not detected by the type system but will certainly end in runtime failures. This is a very unfortunate situation. The Eiffel agent mechanism is quite verbose, the user has to type in a lot of typing information. At the same time the type system gives the programmer no safety.
+At the same time feature foo gives almost no guarantees about how it will use agent f. It calls the agent without passing any arguments. This is not detected by the type system but will certainly end in runtime failures. This is a very unfortunate situation. The Eiffel agent mechanism is quite verbose, the user has to type in a lot of typing information. At the same time the type system gives the programmer no safety. So besides CAT-calls, this is the second type hole in the Eiffel type system.

@@ Line 2: / Line 2: @@
 <code>[eiffel,N]
-foo (f: FUNCTION [A, TUPLE [B], C])
+foo (f: FUNCTION [A, TUPLE [B], C]): C
 </code>
@@ Line 9: / Line 14: @@
 * have at least one open argument. The type of it needs to be a descendant of class B.
 * refer to a feature with a return type that is a descendant of class B.