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

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?

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

2007-06-24T19:08:03Z

‎Vision 2 Example: Thanks for the correction Peter

Peter gummer: /* Vision 2 Example */

2007-06-24T19:03:25Z

‎Vision 2 Example

Juliant at 18:40, 24 June 2007

2007-06-24T18:40:45Z

Manus: /* Vision 2 Example */

2007-06-24T13:08:33Z

‎Vision 2 Example

Seilerm: /* Vision 2 Example */

2007-06-23T23:01:06Z

‎Vision 2 Example

Seilerm: /* Vision 2 Example */

2007-06-23T22:52:00Z

‎Vision 2 Example

Seilerm: /* Vision 2 Example */

2007-06-23T22:48:14Z

‎Vision 2 Example

Seilerm: /* Vision 2 Example */

2007-06-23T22:46:30Z

‎Vision 2 Example

@@ Line 54: / Line 54: @@
        -- Print all attributes of each person in the list.
      do
-       from
+       across a_list as it
-        a_list.start
+       loop
-      until
-        a_list.after
-       do
            -- Reading is valid on a covariant list
-        a_list.item.print
+          it.item.print
        end
      end

@@ Line 216: / Line 216: @@
 Now with this the actual signature of <e>{EV_PND_MOTION_ACTION_SEQUENCE}.extend</e> looks like this:
 <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>

@@ Line 196: / Line 196: @@
 </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>
 class

@@ Line 196: / Line 196: @@
 </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>
 class

@@ Line 1: / Line 1: @@
 [[Category:ECMA]]
 [[Category:Catcall]]
 == Introduction ==

@@ Line 186: / Line 186: @@
      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;
          -- Use this to circumvent tuple type checking. (at your own risk!)
          -- 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>

@@ 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.
 <e>
    force_extend (action: PROCEDURE [ANY, TUPLE]) is
        -- Extend without type checking. Not type save! Use on your own risk!
@@ Line 198: / Line 197: @@
 <e>
 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
    -- old ARRAYED_LIST [PROCEDURE [ANY, EVENT_DATA]]
 </e>
@@ Line 218: / Line 211: @@
      -- 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]]
 </e>
 Now with this the actual signature of <e>{EV_PND_MOTION_ACTION_SEQUENCE}.extend</e> looks like this:
 <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>
 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>
-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>

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

@@ 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.
-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>