[[Image:LogoWarning|24px]] '''Caution:''' {{{1}}}
+[[Image:LogoWarning|24px]] '''Caution:''' {{{1}}}
diff --git a/documentation/current/method/eiffel-tutorial-et/et-inheritance.wiki b/documentation/current/method/eiffel-tutorial-et/et-inheritance.wiki index f284f439..50ee8cf8 100644 --- a/documentation/current/method/eiffel-tutorial-et/et-inheritance.wiki +++ b/documentation/current/method/eiffel-tutorial-et/et-inheritance.wiki @@ -96,8 +96,7 @@ which will assign to acc a reference attached (if not void) to a
Such an assignment, where the source and target types are different, is said to be polymorphic. An entity such as acc , which as a result of such assignments may become attached at run time to objects of types other than the one declared for it, is itself called a polymorphic entity.
For polymorphism to respect the reliability requirements of Eiffel, it must be controlled by the type system and enable static type checking. We certainly do not want an entity of type ACCOUNT to become attached to an object of type DEPOSIT . Hence the second typing rule:
-
-{{note| '''Type Conformance rule '''An assignment x := y, or the use of y as actual argument corresponding to the formal argument x in a routine call, is only valid if the type of y conforms to the the type of x . }}
+{{rule|Type Conformance|An assignment x := y, or the use of y as actual argument corresponding to the formal argument x in a routine call, is only valid if the type of y conforms to the the type of x. }}
The second case listed in the rule is a call such as target.routine(..., y, ...) where the routine declaration is of the form routine (..., x: SOME_TYPE) . The relationship between y , the actual argument in the call, and the corresponding formal argument x , is exactly the same as in an assignment x := y : not just the type rule, as expressed by Type Conformance (the type of y must conform to SOME_TYPE ), but also the actual run-time effect which, as for assignments, will be either a reference attachment or, for expanded types, a copy.
diff --git a/documentation/current/solutions/basic-computing/eiffelbase/eiffelbase-tutorial/eiffelbase-data-structures-overview/index.wiki b/documentation/current/solutions/basic-computing/eiffelbase/eiffelbase-tutorial/eiffelbase-data-structures-overview/index.wiki
index 86b7b1c0..94ae3b62 100644
--- a/documentation/current/solutions/basic-computing/eiffelbase/eiffelbase-tutorial/eiffelbase-data-structures-overview/index.wiki
+++ b/documentation/current/solutions/basic-computing/eiffelbase/eiffelbase-tutorial/eiffelbase-data-structures-overview/index.wiki
@@ -9,14 +9,4 @@ The highest-level class is [[ref:libraries/base/reference/container_chart| CONTA
* [[ref:libraries/base/reference/box_chart|BOX]] , which describes their storage properties, such as being bounded or unbounded.
The documentation further discusses:
-* The [[EiffelBase, Abstract Container Structures: The Taxonomy|taxonomy]] of the abstract container structures.
-* The [[EiffelBase Data Structures, Lists|list-based structures hierarchy]] .
-* The [[EiffelBase, Dispensers|dispenser-based structures hierarchy]] .
-* The [[EiffelBase, Trees|tree-based structures hierarchy]] .
-* The [[EiffelBase, Sets|set-based structures hierarchy]] .
-* The [[EiffelBase, Tables|table-based structures hierarchy]] .
-* The [[EiffelBase, Iteration|iteration mechanisms]] .
-
-
-