Author:admin

Date:2008-09-28T19:59:45.000000Z


git-svn-id: https://svn.eiffel.com/eiffel-org/trunk@59 abb3cda0-5349-4a8f-a601-0c33ac3a8c38

documentation/current/method/eiffel-tutorial-et/et-inheritance.wiki

@@ -96,7 +96,7 @@ which will assign to <code> acc </code> 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 <code> acc </code>, 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 <code> ACCOUNT </code> to become attached to an object of type <code> DEPOSIT </code>. Hence the second typing rule: 
-{{rule|Type Conformance|An assignment <code>x := y</code>, 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 <code>x :&#61; y</code>, 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 <code> target.routine(..., y, ...) </code> where the routine declaration is of the form <code> routine (..., x: SOME_TYPE) </code>. The relationship between <code> y </code>, the actual argument in the call, and the corresponding formal argument <code> x </code>, is exactly the same as in an assignment <code> x := y </code>: not just the type rule, as expressed by Type Conformance (the type of <code> y </code> must conform to <code> SOME_TYPE </code>), but also the actual run-time effect which, as for assignments, will be either a reference attachment or, for expanded types, a copy. 
 

documentation/current/solutions/basic-computing/eiffelbase/eiffelbase-tutorial/eiffelbase-data-structures-overview/eiffelbase-iteration.wiki

@@ -51,6 +51,8 @@ The classes of the Iteration library address this need. Using them offers two be
 
 =Simple Examples=
 
+
+
 To get a first grasp of how one can work with the Iteration library, let us look at a typical iteration class and a typical iteration client.
 
 ==An example iterator routine==
@@ -172,7 +174,9 @@ There are only four Iteration classes, whose simple inheritance structure appear
 
 As you will remember from the [[EiffelBase, Abstract Container Structures: The Taxonomy|presentation]]  of the abstract overall taxonomy, the traversal hierarchy describes how data structures can be traversed; its most general class is [[ref:/libraries/base/reference/two_way_list_chart|TRAVERSABLE]] . <br/>
 Each one of the iterator classes is paired with a traversal class (or two in one case): 
-{| 
+
+
+{| border="1"
 |- 
 | [[ref:/libraries/base/reference/iterator_chart|ITERATOR]] 
 | [[ref:/libraries/base/reference/two_way_list_chart|TRAVERSABLE]] 
@@ -190,6 +194,7 @@ Each one of the iterator classes is paired with a traversal class (or two in one
 | [[ref:/libraries/base/reference/cursor_tree_chart|CURSOR_TREE]] 
 |}
 
+
 Each iterator class relies on the corresponding traversal class to provide the features for traversing the corresponding data structures, such as <eiffel>start</eiffel>, <eiffel>forth</eiffel> and <eiffel>exhausted</eiffel> for linear structures. <br/>
 Of course the data structure class used in connection with a given iterator class does not need to be the iterator's exact correspondent as given by the above table; it may be any one of its descendants. For example you may use [[ref:/libraries/base/reference/linear_iterator_chart|LINEAR_ITERATOR]]  to iterate over data structures described not just by [[ref:/libraries/base/reference/linear_chart|LINEAR]]  but also by such descendants as [[ref:/libraries/base/reference/list_chart|LIST]] , [[ref:/libraries/base/reference/linked_list_chart|LINKED_LIST]] , [[ref:/libraries/base/reference/arrayed_list_chart|ARRAYED_LIST]] , or even [[ref:/libraries/base/reference/two_way_list_chart|TWO_WAY_LIST]]  if you do not need the backward iteration features (for which you will have to use [[ref:/libraries/base/reference/two_way_chain_iterator_chart|TWO_WAY_CHAIN_ITERATOR]]  ).