Covariance through renaming - Revision history

Conaclos: Correction

2013-05-07T21:19:25Z

Correction

Conaclos: general syntax and pattern update

2013-05-07T11:53:49Z

general syntax and pattern update

Conaclos: Syntax and pattern update

2013-05-07T11:46:04Z

Syntax and pattern update

Peter gummer: /* Discussion */

2007-03-18T11:49:13Z

‎Discussion

Peter gummer: /* Solution 1: explicit exception */

2007-03-18T11:45:03Z

‎Solution 1: explicit exception

Peter gummer: /* Example */

2007-03-18T11:38:36Z

‎Example

Peter gummer at 11:33, 18 March 2007

2007-03-18T11:33:03Z

Schoelle: No construction

2007-03-18T10:13:49Z

No construction

Manus: added category

2007-02-22T16:43:59Z

added category

Schoelle: /* Discussion */

2007-02-21T14:47:32Z

‎Discussion

@@ Line 62: / Line 62: @@
 <e>
-interface class
+class
    GRASS
 inherit
    FOOD
 feature

@@ Line 13: / Line 13: @@
 feature -- Access
-   last_food: FOOD
+   last_food: detachable FOOD
 feature -- Eating
-   eat (f: FOOD) is
+   eat (f: FOOD)
-    require
-      not_void: f /= Void
      do
        last_food := f
@@ Line 24: / Line 22: @@
        last_food = f
      end
 end
 </e>
@@ Line 35: / Line 34: @@
 feature -- Access
    is_vegetarian: BOOLEAN
 end
 </e>
@@ Line 51: / Line 51: @@
 feature -- Eating
-   eat (g: GRASS) is
+   eat (g: GRASS)
      do
        last_food := g
@@ Line 64: / Line 64: @@
 interface class
    GRASS
 inherit
    FOOD
-invariant
+feature
-   grass_is_vegetarian: is_vegetarian
+   is_vegetarian: BOOLEAN = True
 end
 </e>
@@ Line 78: / Line 82: @@
 local
    a_cow: COW
-   a_animal: ANIMAL
+   an_animal: ANIMAL
 do
    create a_cow
    an_animal := a_cow
-   an_animal.eat (create {FOOD}) -- CAT call!
+   an_animal.eat (create {FOOD}) -- CAT call
 end
 </e>
@@ Line 107: / Line 111: @@
 feature -- Eating
-   eat (g: GRASS) is
+   eat (g: GRASS)
-    require
-      not_void: g /= Void
      do
        last_food := g
@@ Line 116: / Line 118: @@
      end
-   animal_eat (f: FOOD) is
+   animal_eat (f: FOOD)
-    local
-      g: GRASS
      do
-       g ?= f
+       if attached {GRASS} f as g then
-      if g /= Void then
          eat (g)
        else
-         raise (1,"CAT call")
+         raise (1, "CAT call")
        end
      end
 invariant
-   only_eats_vegetarian: last_food.is_vegetarian
+   only_eats_vegetarian: (attached last_food as food) implies food.is_vegetarian
 end
 </e>

@@ Line 146: / Line 146: @@
 feature -- Access
-   last_food: FOOD
+   last_food: detachable FOOD
 feature -- Status report
    likes (f: FOOD): BOOLEAN
-   likes (f: FOOD): BOOLEAN is
-    require
-      not_void: f /= Void
      do
        Result := True
@@ Line 158: / Line 155: @@
 feature -- Eating
-   eat (f: FOOD) is
+   eat (f: FOOD)
      require
        likes (f)
@@ Line 166: / Line 163: @@
        last_food = f
      end
 end
 </e>
@@ Line 183: / Line 181: @@
 feature -- Status report
-   likes (f: FOOD): BOOLEAN is
+   likes (f: FOOD): BOOLEAN
-    local
-      g: GRASS
      do
-      g ?= f
+       Result := attached {GRASS} f
-       Result := (g /= Void)
      end
 feature -- Eating
-   eat (g: GRASS) is
+   eat (g: GRASS)
      do
        last_food := g
      end
-   animal_eat (f: FOOD) is
+   animal_eat (f: FOOD)
-    local
-      g: GRASS
      do
-       g ?= f -- We can assume that this will succeed from the local definition of `likes'.
+       check attached {GRASS} f as g then
-      eat (g)
+        eat (g)
      end
 invariant
-   only_eats_vegetarian: last_food /= Void implies last_food.is_vegetarian
+   only_eats_vegetarian: (attached last_food as food) implies food .is_vegetarian
 end
 </e>

@@ Line 214: / Line 214: @@
 From the perspective of the interface, the covariant and the renaming solutions all have the same interface, with the exception that in the renaming cases, COW also has an `animal_eat' command that it inherits from ANIMAL. Though this may seem unwanted, it makes the generation of flattened forms easier and also shows that the 'eat' of ANIMAL and 'eat' of COW are not the same features.
-Also, we '''do not address the problems of CAT calls through genericity and change of export status'''. These problems need a different treatment (for example though the restriction of the interface though readonly types).
+Also, we '''do not address the problems of CAT calls through genericity and change of export status'''. These problems need a different treatment (for example through the restriction of the interface through readonly types).
-Interestingly, the approach can be used to model any change of signature, including covariant, contravariant arguments, covariant and contravariant return types and even the change of existing or the introduction of new arguments. It is thus more powerful than the covariant mechansims available in Eiffel.
+Interestingly, the approach can be used to model any change of signature, including covariant, contravariant arguments, covariant and contravariant return types and even the change of existing or the introduction of new arguments. It is thus more powerful than the covariant mechanisms available in Eiffel.

@@ Line 135: / Line 135: @@
 We have renamed 'eat' to 'animal_eat', to create space for a different feature 'eat' that is adequate for cows. We implement 'animal_eat' in terms of 'eat' if the supplied food is the right one. Otherwise, we have the conditions of a CAT call and raise an exception.
-The advantage of this solution is that it does clearly show that it is possible to get an exception through calling 'animal_eat' in COWs. It does not help preventing the exception from occuring, but it shows that there is a deficiency in the code that needs to be taken care of.
+The advantage of this solution is that it does clearly show that it is possible to get an exception through calling 'animal_eat' in COWs. It does not help preventing the exception from occurring, but it shows that there is a deficiency in the code that needs to be taken care of.
 == Solution 2: stronger precondition ==

@@ Line 86: / Line 86: @@
 </e>
-What is the origin of the CAT call? The error comes from strengthening the precondition of eat through the type system. The precondition in ANIMAL states something like "I will eat everything, as long as it is FOOD", while the precondition in COW states: "I will eat everything, as long as it is GRASS." - so we are faceing a miss-use of the inheritance relation, as a COW is not an ANIMAL - at least not when it comes to food consumption.
+What is the origin of the CAT call? The error comes from strengthening the precondition of eat through the type system. The precondition in ANIMAL states something like "I will eat everything, as long as it is FOOD", while the precondition in COW states: "I will eat everything, as long as it is GRASS." - so we are facing a miss-use of the inheritance relation, as a COW is not an ANIMAL - at least not when it comes to food consumption.
 It is a very typical problem of object-oriented modelling, as the subtype relation not only describes a 'COW is an ANIMAL' (observation) but also a 'what we can do to an ANIMAL, we can also do to a COW' (modification) relation.

← Older revision		Revision as of 11:33, 18 March 2007
Line 2:		Line 2:


−	Covariant arguments are part of the Eiffel language, introducing the known problems of CAT calls and global analysis. This page summarizes how to solve a classic covariant problem purely ~~though~~ the well-known and understood renaming mechanism in Eiffel. We will see that this solution is more verbose than the covariant solution, but has a set of advantages, including the explicit need to rework the contract, define handlers for CAT calls or the explicit creation of exceptions.	+	Covariant arguments are part of the Eiffel language, introducing the known problems of CAT calls and global analysis. This page summarizes how to solve a classic covariant problem purely through the well-known and understood renaming mechanism in Eiffel. We will see that this solution is more verbose than the covariant solution, but has a set of advantages, including the explicit need to rework the contract, define handlers for CAT calls or the explicit creation of exceptions.

	== Example ==		== Example ==

@@ Line 1: / Line 1: @@
 [[Category:ECMA]]
-{{Warning|'''Warning''': Article under development}}
 Covariant arguments are part of the Eiffel language, introducing the known problems of CAT calls and global analysis. This page summarizes how to solve a classic covariant problem purely though the well-known and understood renaming mechanism in Eiffel. We will see that this solution is more verbose than the covariant solution, but has a set of advantages, including the explicit need to rework the contract, define handlers for CAT calls or the explicit creation of exceptions.

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