From 39c34b0898d048c368f1258cb5e6a76c5aa553f1 Mon Sep 17 00:00:00 2001
From: halw <halw@abb3cda0-5349-4a8f-a601-0c33ac3a8c38>
Date: Fri, 16 Sep 2011 14:15:29 +0000
Subject: [PATCH] Added definition template for "conformance".

Author:halw
Date:2011-09-16T14:15:29.000000Z


git-svn-id: https://svn.eiffel.com/eiffel-org/trunk@972 abb3cda0-5349-4a8f-a601-0c33ac3a8c38
---
 .../current/method/eiffel-tutorial-et/et-inheritance.wiki    | 5 ++++-
 1 file changed, 4 insertions(+), 1 deletion(-)

diff --git a/documentation/current/method/eiffel-tutorial-et/et-inheritance.wiki b/documentation/current/method/eiffel-tutorial-et/et-inheritance.wiki
index c172ea31..8f529a42 100644
--- a/documentation/current/method/eiffel-tutorial-et/et-inheritance.wiki
+++ b/documentation/current/method/eiffel-tutorial-et/et-inheritance.wiki
@@ -100,7 +100,10 @@ Besides changing the implementation of a routine, a redefinition can turn an arg
 
 The inheritance mechanism is relevant to both roles of classes: module and type. Its application as a mechanism to reuse, adapt and extend features from one class to another, as just seen, covers its role as a '''module extension''' mechanism. But it's also a '''subtyping''' mechanism. To say that <code>D</code> is an heir of <code>A</code>, or more generally a descendant of <code>A</code>, is to express that instances of <code>D</code> can be viewed as instances of <code>A</code>. 
 
-'''Polymorphic assignment''' supports this second role. In an assignment <code>x := y</code>, the types of <code>x</code> and <code>y</code> do not have, with inheritance, to be identical; the rule is that the type of <code>y</code> must simply '''conform''' to the type of <code>x</code>. A class <code>D</code> conforms to a class <code>A</code> if and only if it is a descendant of <code>A</code> (which includes the case in which <code>A</code> and <code>D</code> are the same class); if these classes are generic, conformance of <code>D</code> <code>[</code> <code>U</code> <code>]</code> to <code>C</code> <code>[</code> <code>T</code> <code>]</code> requires in addition that type <code>U</code> conform to type <code>T</code> (through the recursive application of the same rules). 
+'''Polymorphic assignment''' supports this second role. In an assignment <code>x := y</code>, the types of <code>x</code> and <code>y</code> do not have, with inheritance, to be identical; the rule is that the type of <code>y</code> must simply '''conform''' to the type of <code>x</code>. 
+
+
+{{definition|Conformance|A class <code>D</code> conforms to a class <code>A</code> if and only if it is a descendant of <code>A</code> (which includes the case in which <code>A</code> and <code>D</code> are the same class); if these classes are generic, conformance of <code>D</code> <code>[U]</code> to <code>C</code> <code>[T]</code> requires in addition that type <code>U</code> conform to type <code>T</code> (through the recursive application of the same rules). }}
 
 
 {{note|In addition, it will be shown in the discussion of tuples ([[ET: Other Mechanisms#Tuple_types|"Tuple types"]]), that <code>TUPLE [X]</code> conforms to <code>TUPLE</code>, <code>TUPLE [X, Y]</code> to <code>TUPLE [X]</code> and so on. }}