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

← Older revision		Revision as of 04:27, 20 April 2007
Line 258:		Line 258:
	=== 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~~.		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:		Example:

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

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

Manus at 10:15, 11 April 2007

2007-04-11T10:15:55Z

← Older revision		Revision as of 10:15, 11 April 2007
Line 1:		Line 1:
	[[Category:ECMA]]		[[Category:ECMA]]
	{{~~Warning\|'''Warning''': Article under development~~}}		{{UnderConstruction}}

	==Introduction==		==Introduction==

Chengchangwu: /* Introduction */

2007-04-09T02:07:41Z

Introduction

← Older revision		Revision as of 02:07, 9 April 2007
Line 31:		Line 31:
	l_student: STUDENT		l_student: STUDENT
	l_any_stack: STACK [PERSON]		l_any_stack: STACK [PERSON]
	~~l_integer_stack~~: STACK [STUDENT]		l_student_stack: STACK [STUDENT]
	do		do
	l_person_stack := l_student_stack -- line 1		l_person_stack := l_student_stack -- line 1

Seilerm at 21:11, 8 April 2007

2007-04-08T21:11:56Z

← Older revision		Revision as of 21:11, 8 April 2007
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>.		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.		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?		{{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 ==		== Validity ==

Juliant: /* Semantics */

2007-04-08T02:33:38Z

Semantics

← Older revision		Revision as of 02:33, 8 April 2007
Line 98:		Line 98:

	{{Note\| Why do we need that?		{{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 ==		== Validity ==

Juliant: /* Conformance Rules */

2007-04-08T01:28:27Z

Conformance Rules

← Older revision		Revision as of 01:28, 8 April 2007
Line 110:		Line 110:
	==Conformance Rules==		==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:		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
			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.

	<e>		<e>
Line 202:		Line 204:
	T := LIST [ANY..T] .item		T := LIST [ANY..T] .item
	</e>		</e>


	==Agents==		==Agents==

Juliant: /* Semantics */

2007-04-08T01:19:34Z

Semantics

← Older revision		Revision as of 01:19, 8 April 2007
Line 97:		Line 97:
	If we encounter a form like LIST [A..] it simply means that no feature which has the formal in the argument can be called.		If we encounter a form like LIST [A..] it simply means that no feature which has the formal in the argument can be called.

	{{Note: Why do we need that?		{{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 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.}}


	== Validity ==		== Validity ==

Seilerm at 00:21, 8 April 2007

2007-04-08T00:21:31Z

← Older revision		Revision as of 00:21, 8 April 2007
Line 219:		Line 219:
	</e>		</e>

	==~~agent (T)~~==		=== Agent example ===

	Type declaration:		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.		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.		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.

Seilerm at 00:20, 8 April 2007

2007-04-08T00:20:02Z

← Older revision		Revision as of 00:20, 8 April 2007
Line 37:		Line 37:
	l_student := l_student_stack.item -- line 3		l_student := l_student_stack.item -- line 3
	</e>		</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>.		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>.