Usage-site variance - Revision history

Conaclos: Syntax update and correction of infinite loop

2013-05-08T16:59:32Z

Syntax update and correction of infinite loop

← Older revision		Revision as of 16:59, 8 May 2013
Line 54:		Line 54:
	-- Print all attributes of each person in the list.		-- Print all attributes of each person in the list.
	do		do
	~~from~~		across a_list as it
	~~a_list.start~~		loop
	~~until~~
	a_list~~.after~~
	do
	-- Reading is valid on a covariant list		-- Reading is valid on a covariant list
	~~a_list~~.item.print		it.item.print
	end		end
	end		end

Peter gummer: The class should be marked covariant, not the argument, right?

2007-06-24T19:14:13Z

The class should be marked covariant, not the argument, right?

← Older revision		Revision as of 19:14, 24 June 2007
Line 216:		Line 216:
	Now with this the actual signature of <e>{EV_PND_MOTION_ACTION_SEQUENCE}.extend</e> looks like this:		Now with this the actual signature of <e>{EV_PND_MOTION_ACTION_SEQUENCE}.extend</e> looks like this:
	<e>		<e>
	extend (v: PROCEDURE [ANY, -TUPLE [x: INTEGER_32; y: INTEGER_32; +pick_and_dropable: EV_ABSTRACT_PICK_AND_DROPABLE]]		extend (v: PROCEDURE [ANY, -TUPLE [x: INTEGER_32; y: INTEGER_32; pick_and_dropable: +EV_ABSTRACT_PICK_AND_DROPABLE]]
	</e>		</e>

Juliant: /* Vision 2 Example */ Thanks for the correction Peter

2007-06-24T19:08:03Z

Vision 2 Example: Thanks for the correction Peter

← Older revision		Revision as of 19:08, 24 June 2007
Line 196:		Line 196:
	</e>		</e>

	If this solution is built into Eiffel the designer of Vision2 would do a small change in <e>ACTION_SEQUENCE</e>. The changes makes sure that we can accept agents to features defined in ~~ancestors (--[[User:Peter gummer\|Peter gummer]] 21:03, 24 June 2007 (CEST) Shouldn't this be ''~~descendants~~''?)~~ of <e>ANY</e> (therefore the <e>+ANY</e>) and that we accept agents which are not interested in all data but just (possibly) take parts of it (therefore <e>-EVENT_DATA</e>).		If this solution is built into Eiffel the designer of Vision2 would do a small change in <e>ACTION_SEQUENCE</e>. The changes makes sure that we can accept agents to features defined in descendants of <e>ANY</e> (therefore the <e>+ANY</e>) and that we accept agents which are not interested in all data but just (possibly) take parts of it (therefore <e>-EVENT_DATA</e>).
	<e>		<e>
	class		class

Peter gummer: /* Vision 2 Example */

2007-06-24T19:03:25Z

Vision 2 Example

← Older revision		Revision as of 19:03, 24 June 2007
Line 196:		Line 196:
	</e>		</e>

	If this solution is built into Eiffel the designer of Vision2 would do a small change in <e>ACTION_SEQUENCE</e>. The changes makes sure that we can accept agents to features defined in ancestors of <e>ANY</e> (therefore the <e>+ANY</e>) and that we accept agents which are not interested in all data but just (possibly) take parts of it (therefore <e>-EVENT_DATA</e>).		If this solution is built into Eiffel the designer of Vision2 would do a small change in <e>ACTION_SEQUENCE</e>. The changes makes sure that we can accept agents to features defined in ancestors (--[[User:Peter gummer\|Peter gummer]] 21:03, 24 June 2007 (CEST) Shouldn't this be ''descendants''?) of <e>ANY</e> (therefore the <e>+ANY</e>) and that we accept agents which are not interested in all data but just (possibly) take parts of it (therefore <e>-EVENT_DATA</e>).
	<e>		<e>
	class		class

Juliant at 18:40, 24 June 2007

2007-06-24T18:40:45Z

← Older revision		Revision as of 18:40, 24 June 2007
Line 1:		Line 1:
	[[Category:ECMA]]		[[Category:ECMA]]
	[[Category:Catcall]]		[[Category:Catcall]]
			{{Research}}
	== Introduction ==		== Introduction ==

Manus: /* Vision 2 Example */

2007-06-24T13:08:33Z

Vision 2 Example

← Older revision		Revision as of 13:08, 24 June 2007
Line 186:		Line 186:
	end		end

	wrapper (an_x, a_y: INTEGER; a_pick_and_dropable: EV_ABSTRACT_PICK_AND_DROPABLE; action: PROCEDURE [ANY, TUPLE]) is		wrapper (an_x, a_y: INTEGER; a_pick_and_dropable: EV_ABSTRACT_PICK_AND_DROPABLE;
			action: PROCEDURE [ANY, TUPLE])
	-- Use this to circumvent tuple type checking. (at your own risk!)		-- Use this to circumvent tuple type checking. (at your own risk!)
	-- Calls `action' passing all other arguments.		-- Calls `action' passing all other arguments.
	do		do
	action.call ([an_x, a_y, a_pick_and_dropable])		action.call ([an_x, a_y, a_pick_and_dropable])
	end		end
	</e>		</e>

Seilerm: /* Vision 2 Example */

2007-06-23T23:01:06Z

Vision 2 Example

← Older revision		Revision as of 23:01, 23 June 2007
Line 180:		Line 180:
	The following code is taken from <e>EV_PND_MOTION_ACTION_SEQUENCE</e>. Here we gain the flexibility that an agent which listens to the event does not have to be a feature which takes all the data provided if the event occurs. Maybe the programmer is just interested in the fact that an actual event occurred and not in the data about it.		The following code is taken from <e>EV_PND_MOTION_ACTION_SEQUENCE</e>. Here we gain the flexibility that an agent which listens to the event does not have to be a feature which takes all the data provided if the event occurs. Maybe the programmer is just interested in the fact that an actual event occurred and not in the data about it.
	<e>		<e>

	force_extend (action: PROCEDURE [ANY, TUPLE]) is		force_extend (action: PROCEDURE [ANY, TUPLE]) is
	-- Extend without type checking. Not type save! Use on your own risk!		-- Extend without type checking. Not type save! Use on your own risk!
Line 198:		Line 197:
	<e>		<e>
	class		class
	ACTION_SEQUENCE [EVENT_DATA -> +TUPLE create default_create end]		ACTION_SEQUENCE [EVENT_DATA -> TUPLE create default_create end]
	~~-- Note `+' in front of `TUPLE' as it is indeed covariant: We accept all kind~~
	~~-- of EVENT_DATA as long it is a descendant of `TUPLE', like `TUPLE [ANY, INTEGER]'.~~

	inherit		inherit
			ARRAYED_LIST [PROCEDURE [+ANY, -EVENT_DATA]]
	-- old ARRAYED_LIST [PROCEDURE [ANY, EVENT_DATA]]		-- old ARRAYED_LIST [PROCEDURE [ANY, EVENT_DATA]]
	~~ARRAYED_LIST [PROCEDURE [+ANY, -EVENT_DATA]]~~
	~~rename~~
	~~-- ...~~
	~~end~~
	</e>		</e>

Line 218:		Line 211:
	-- old EV_ACTION_SEQUENCE [TUPLE [x: INTEGER; y: INTEGER; pick_and_dropable: EV_ABSTRACT_PICK_AND_DROPABLE]]		-- old EV_ACTION_SEQUENCE [TUPLE [x: INTEGER; y: INTEGER; pick_and_dropable: EV_ABSTRACT_PICK_AND_DROPABLE]]
	EV_ACTION_SEQUENCE [TUPLE [x: INTEGER; y: INTEGER; pick_and_dropable: +EV_ABSTRACT_PICK_AND_DROPABLE]]		EV_ACTION_SEQUENCE [TUPLE [x: INTEGER; y: INTEGER; pick_and_dropable: +EV_ABSTRACT_PICK_AND_DROPABLE]]
	~~...~~
	~~end~~
	</e>		</e>
	Now with this the actual signature of <e>{EV_PND_MOTION_ACTION_SEQUENCE}.extend</e> looks like this:		Now with this the actual signature of <e>{EV_PND_MOTION_ACTION_SEQUENCE}.extend</e> looks like this:
	<e>		<e>
	extend (v: PROCEDURE [ANY, -TUPLE [x: INTEGER_32; y: INTEGER_32; +pick_and_dropable: EV_ABSTRACT_PICK_AND_DROPABLE]]		extend (v: PROCEDURE [ANY, -TUPLE [x: INTEGER_32; y: INTEGER_32; +pick_and_dropable: EV_ABSTRACT_PICK_AND_DROPABLE]]
	</e>		</e>

	For the sake of completeness the signature of <e>{EV_PND_MOTION_ACTION_SEQUENCE}.call</e>. Note again that the the field `pick_and_dropable' is covariant allowing to call the event with tuples containing descendants of <e>EV_ABSTRACT_PICK_AND_DROPABLE</e>.		For the sake of completeness the signature of <e>{EV_PND_MOTION_ACTION_SEQUENCE}.call</e>. Note again that the the field `pick_and_dropable' is covariant allowing to call the event with tuples containing descendants of <e>EV_ABSTRACT_PICK_AND_DROPABLE</e>.
	<e>		<e>
	call (event_data: TUPLE [x: INTEGER_32; y: INTEGER_32; pick_and_dropable: +EV_ABSTRACT_PICK_AND_DROPABLE])		call (event_data: TUPLE [x: INTEGER_32; y: INTEGER_32; pick_and_dropable: +EV_ABSTRACT_PICK_AND_DROPABLE])
	</e>		</e>

Seilerm: /* Vision 2 Example */

2007-06-23T22:52:00Z

Vision 2 Example

← Older revision		Revision as of 22:52, 23 June 2007
Line 198:		Line 198:
	<e>		<e>
	class		class
	ACTION_SEQUENCE [EVENT_DATA -> +TUPLE create default_create end]		ACTION_SEQUENCE [EVENT_DATA -> +TUPLE create default_create end]
	-- Note `+' in front of `TUPLE' as it is indeed covariant: We accept all kind		-- Note `+' in front of `TUPLE' as it is indeed covariant: We accept all kind
	-- of EVENT_DATA as long it is a descendant of `TUPLE', like `TUPLE [ANY, INTEGER]'.		-- of EVENT_DATA as long it is a descendant of `TUPLE', like `TUPLE [ANY, INTEGER]'.

	inherit		inherit
	-- old ARRAYED_LIST [PROCEDURE [ANY, EVENT_DATA]]		-- old ARRAYED_LIST [PROCEDURE [ANY, EVENT_DATA]]
	ARRAYED_LIST [PROCEDURE [+ANY, -EVENT_DATA]]		ARRAYED_LIST [PROCEDURE [+ANY, -EVENT_DATA]]
	rename		rename
	-- ...		-- ...
	end		end
	</e>		</e>

Seilerm: /* Vision 2 Example */

2007-06-23T22:48:14Z

Vision 2 Example

← Older revision		Revision as of 22:48, 23 June 2007
Line 182:		Line 182:

	force_extend (action: PROCEDURE [ANY, TUPLE]) is		force_extend (action: PROCEDURE [ANY, TUPLE]) is
	-- Extend without type checking.		-- Extend without type checking. Not type save! Use on your own risk!
	do		do
	extend (agent wrapper (?, ?, ?, action))		extend (agent wrapper (?, ?, ?, action))
Line 206:		Line 206:
	ARRAYED_LIST [PROCEDURE [+ANY, -EVENT_DATA]]		ARRAYED_LIST [PROCEDURE [+ANY, -EVENT_DATA]]
	rename		rename
	~~make as arrayed_list_make~~		-- ...
	~~export~~
	~~{ACTION_SEQUENCE} same_items, subarray~~
	~~redefine~~
	~~default_create,~~
	~~set_count~~
	end		end
	</e>		</e>

Seilerm: /* Vision 2 Example */

2007-06-23T22:46:30Z

Vision 2 Example

← Older revision		Revision as of 22:46, 23 June 2007
Line 178:		Line 178:
	A field which makes heavy use of agents and benefits a lot of them is ''event driven programming''. With the current agent mechanism the programmer is sometimes forced to use a hack to circumvent the type checker in order to gain flexibility.		A field which makes heavy use of agents and benefits a lot of them is ''event driven programming''. With the current agent mechanism the programmer is sometimes forced to use a hack to circumvent the type checker in order to gain flexibility.

	The following code is taken from <e>EV_PND_MOTION_ACTION_SEQUENCE</e>. Here we gain the flexibility that an agent which listens to the event does not have to be a feature which takes all the data provided if the event occurs. Maybe the programmer is just ~~intrested~~ in the fact that an actual event occurred and not in the data about it.		The following code is taken from <e>EV_PND_MOTION_ACTION_SEQUENCE</e>. Here we gain the flexibility that an agent which listens to the event does not have to be a feature which takes all the data provided if the event occurs. Maybe the programmer is just interested in the fact that an actual event occurred and not in the data about it.
	<e>		<e>