mirrors/eiffel-org
1
0
Fork 0
mirror of https://github.com/EiffelSoftware/eiffel-org.git synced 2025-12-07 15:22:31 +01:00
Code Issues Packages Projects Releases Wiki Activity

Author:halw

Browse Source 
Date:2010-01-14T17:24:57.000000Z


git-svn-id: https://svn.eiffel.com/eiffel-org/trunk@395 abb3cda0-5349-4a8f-a601-0c33ac3a8c38
This commit is contained in:
halw
2010-01-14 17:24:57 +00:00
parent 83543b0afc
commit cbbee74365
1 changed files with 7 additions and 5 deletions
Download Patch File Download Diff File Expand all files Collapse all files

12
documentation/current/method/eiffel-tutorial-et/et-inheritance.wiki
View File

@@ -750,7 +750,7 @@ Assignment attempt is useful in the cases cited -- access to external objects be
{{note|As a consequence of the advent of [[Void-safe programming in Eiffel|void-safe Eiffel]], an elegant language construct has been added to Eiffel which can be used in place of the assignment attempt. The [[Void-safety: Background, definition, and tools#The attached syntax (object test)|attached syntax]] can be used to test for an attached object (object test), but it can also be used as to provide a convenient [[Creating a new void-safe project#As a replacement for assignment attempt|replacement for the assignment attempt]] which does not require the separate declaration of a local variable.}}
==Covariance and anchored declarations==
==Covariance, anchored declarations, and "catcalls"==
The final property of Eiffel inheritance involves the rules for adapting not only the implementation of inherited features (through redeclaration of either kind, effecting and redefinition, as seen so far) and their contracts (through the Assertion Redeclaration rule), but also their types. More general than type is the notion of a feature's '''signature''', defined by the number of its arguments, their types, the indication of whether it has a result (that is to say, is a function or attribute rather than a procedure) and, if so, the type of the result.
@@ -879,7 +879,7 @@ Likewise the compiler in EiffelStudio will produce warnings in cases in which ca
===Non-conforming inheritance===
==Non-conforming inheritance==
So far, our experience with inheritance is that of "conforming" inheritance ... the most commonly used type of inheritance. Conforming inheritance is what allows a direct instance (in the '''catcall''' example above) of <code>COW</code> to be attached at runtime to an entity of type <code>ANIMAL</code>. This can be a powerful modeling capability, but it is this same polymorphism facilitated by conforming inheritance that puts us in the danger of using polymorphic '''catcalls'''.
@@ -890,14 +890,16 @@ In order to use non-conforming inheritance for a particular parent, we use the m
<code>
class
MY_HEIR_CLASS
inherit
MY_CONFORMING_PARENT
inherit
{NONE} MY_NON_CONFORMING_PARENT
inherit {NONE}
MY_NON_CONFORMING_PARENT
...
</code>
Here there are two inherit clauses, one to specify conforming parents, and one to specify non-conforming parents. The clause specifying the conforming inheritance must precede the one specifying the non-conforming inheritance.
Here there are two <code>inherit</code> clauses, one to specify conforming parents, and one to specify non-conforming parents. The clause specifying the conforming inheritance must precede the one specifying the non-conforming inheritance.
So, in this case, at runtime it is valid for a direct instance of <code>MY_HEIR_CLASS</code> to be attached to an entity of type <code>MY_CONFORMING_PARENT</code>, but not to an entity of type <code>MY_NON_CONFORMING_PARENT</code>. Accordingly, the compiler would reject any code in which an instance of <code>MY_HEIR_CLASS</code> could become attached to an entity of type <code>MY_NON_CONFORMING_PARENT</code>. Because the polymorphic attachment cannot be made, the possibility of a catcall is avoided.