Preventing CAT calls in Generics - Revision history

Seilerm: /* How to generate the call signature for a given agent type */

2007-04-20T04:27:00Z

‎How to generate the call signature for a given agent type

Juliant: Type Intervall and Generics moved to Preventing CAT calls in Generics: More appropriate title for article

2007-04-11T23:52:29Z

Type Intervall and Generics moved to Preventing CAT calls in Generics: More appropriate title for article

Manus at 10:15, 11 April 2007

2007-04-11T10:15:55Z

Chengchangwu: /* Introduction */

2007-04-09T02:07:41Z

‎Introduction

Seilerm at 21:11, 8 April 2007

2007-04-08T21:11:56Z

Juliant: /* Semantics */

2007-04-08T02:33:38Z

‎Semantics

Juliant: /* Conformance Rules */

2007-04-08T01:28:27Z

‎Conformance Rules

Juliant: /* Semantics */

2007-04-08T01:19:34Z

‎Semantics

Seilerm at 00:21, 8 April 2007

2007-04-08T00:21:31Z

Seilerm at 00:20, 8 April 2007

2007-04-08T00:20:02Z

@@ Line 258: / Line 258: @@
 === How to generate the call signature for a given agent type ===
-To build the signature of the call routine one simply takes he second parameter and move it as the first. As the second parameter we put NONE.
+To build the signature of the call routine one simply takes he second parameter and puts it as the first. As the second parameter we put nothing.
 Example:

@@ Line 1: / Line 1: @@
 [[Category:ECMA]]
-{{Warning|'''Warning''': Article under development}}
+{{UnderConstruction}}
 ==Introduction==

@@ Line 31: / Line 31: @@
    l_student: STUDENT
    l_any_stack: STACK [PERSON]
-   l_integer_stack: STACK [STUDENT]
+   l_student_stack: STACK [STUDENT]
 do
    l_person_stack := l_student_stack -- line 1

@@ Line 39: / Line 39: @@
 Currently no static check will prohibit you from writing things like this. At runtime on ''line 2'' the first CAT call occurs, which most likely wont do any harm to a list. But the object returned by <e>item</e> on ''line 3'' is not of type <e>STUDENT</e> but of type <e>PERSON</e> and at least now we have a serious problem if one invokes features specific to a student on <e>l_student</e>.
-The issue is that the <e>put</e> feature of <e>l_person_stack</e> allows you to put objects of type <e>PERSON</e> on the stack even though the actual type of the attached object is <e>STACK [STUDENT]</e> and is referenced by <e>l_integer_stack</e> whose item feature guarantees, that the returned object will be of type <e>STUDENT</e>.
+The issue is that the <e>put</e> feature of <e>l_person_stack</e> allows you to put objects of type <e>PERSON</e> on the stack even though the actual type of the attached object is <e>STACK [STUDENT]</e> and is referenced by <e>l_student_stack</e> whose <e>item</e> feature guarantees, that the returned object will be of type <e>STUDENT</e>.
 This solution will now extend the type system and the generic derivation of Eiffel in such away, that the type of a formal occurring as an argument in a feature declaration and the type of a formal occurring as a result type can be set independently. The type system will be extended with rules which allow only assignments between generic types if it cannot possibly lead to problems like the one mentioned above.
@@ Line 98: / Line 98: @@
 {{Note| Why do we need that?
-We want to ensure that one has a read only list as if we would do <e>LIST [ANY..NONE]</e> one would not be allowed to assign a <e>LIST [INTEGER]</e> to it as one can put Void into a list of type <e>LIST [ANY..NONE]</e> which is invalid for a list of integer as <e>INTEGER</e> is expanded.}}
+We want to ensure that one has a read only list. One cannot use a <e>LIST [ANY..NONE]</e> because one would not be allowed to assign a <e>LIST [INTEGER]</e> to it. This is because one can put Void into a list of type <e>LIST [ANY..NONE]</e>, which is invalid for a list of integer as <e>INTEGER</e> is expanded.}}
 == Validity ==

@@ Line 98: / Line 98: @@
 {{Note| Why do we need that?
-We wan to ensure that one has a read only list as if we would do <e>LIST [ANY..NONE]</e> one would not be allowed to assign a <e>LIST [INTEGER]</e> to it as one can put Void into a list of tyep <e>LIST [ANY..NONE]</e> which is invalid for a list of integer as <e>INTEGER</e> is expanded.}}
+We want to ensure that one has a read only list as if we would do <e>LIST [ANY..NONE]</e> one would not be allowed to assign a <e>LIST [INTEGER]</e> to it as one can put Void into a list of type <e>LIST [ANY..NONE]</e> which is invalid for a list of integer as <e>INTEGER</e> is expanded.}}
 == Validity ==

← Older revision	Revision as of 23:52, 11 April 2007
(No difference)

@@ Line 110: / Line 110: @@
 ==Conformance Rules==
-We make another more abstract example to illustrate the conformance rules. They can easily be derived by applying the fact that its save for argument types to be covariant and for result types to be contra-variant. This is actually a very important as it is the basis where the conformance is based uppon.
+We make another more abstract example to illustrate the conformance rules. They can easily be derived by applying the fact that its save for argument types to be contra-variant and for result types to be covariant. This is actually a very important as it is the basis where the conformance is based uppon.
 Interface conformance rule:
-  An interface B is conform to an interface A if for every feature f_a in A there is a corresponding feature f_b available from B
+  An interface B is conform to an interface A if for every feature f_a in A
- and for each feature the arguments of f_a conform to those of f_b and the result type of f_b is conform to the one of f_a.
+ there is a corresponding feature f_b available from B and for each feature
 <e>
@@ Line 202: / Line 204: @@
 T := LIST [ANY..T] .item
 </e>
 ==Agents==

@@ Line 219: / Line 219: @@
 </e>
-==agent (T)==
+=== Agent example ===
 Type declaration:
@@ Line 256: / Line 256: @@
 There might be a concern about the fact that the compiler generates the signature of the call method. But I think that its not wrong to have compiler support for agents, as they are such a fundamental core concept that is simply important that one could sacrifice expressive power or type safety just to avoid explicit support from the compiler.
-== How to generate the call signature for a given agent type ==
+=== How to generate the call signature for a given agent type ===
 To build the signature of the call routine one simply takes he second parameter and move it as the first. As the second parameter we put NONE.

@@ Line 37: / Line 37: @@
    l_student := l_student_stack.item -- line 3
 </e>
-Currently no static check will prohibit you from writing things like this. At runtime the object returned by <e>item</e> on ''line 3'' is not of type <e>STUDENT</e> but of type <e>PERSON</e>.
+Currently no static check will prohibit you from writing things like this. At runtime on ''line 2'' the first CAT call occurs, which most likely wont do any harm to a list. But the object returned by <e>item</e> on ''line 3'' is not of type <e>STUDENT</e> but of type <e>PERSON</e> and at least now we have a serious problem if one invokes features specific to a student on <e>l_student</e>.
 The issue is that the <e>put</e> feature of <e>l_person_stack</e> allows you to put objects of type <e>PERSON</e> on the stack even though the actual type of the attached object is <e>STACK [STUDENT]</e> and is referenced by <e>l_integer_stack</e> whose item feature guarantees, that the returned object will be of type <e>STUDENT</e>.