Author:halw

Date:2009-01-28T16:53:41.000000Z


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

documentation/current/method/eiffel-tutorial-et/et-design-contract-tm-assertions-and-exceptions.wiki

@@ -43,7 +43,7 @@ Eiffel provides syntax for expressing preconditions (<code>require</code>), post
 
 Here is a partial update of class <code>ACCOUNT</code> with more assertions: 
 <code>
-indexing
+note
     description: "Simple bank accounts"
 
 class
@@ -175,7 +175,7 @@ When releasing the final version of a system, it is usually appropriate to turn
 
 Another application of assertions governs documentation. Environment mechanisms, such as clicking the <code>Form Contract</code> icon in Eiffelstudio, will produce, from a class text, an abstracted version which only includes the information relevant for client authors. Here is the contract form of class <code>ACCOUNT</code> in the latest version given: 
 <code>
-indexing
+note
     description: "Simple bank accounts"
 
 class interface

documentation/current/method/eiffel-tutorial-et/et-dynamic-structure-execution-model.wiki

@@ -48,7 +48,7 @@ This principle of '''Uniform Access''' is central to Eiffel's goals of extendibi
 
 The following simple class text illustrates the preceding concepts
 <code>
-indexing
+note
     description: "Simple bank accounts"
 
 class
@@ -169,7 +169,7 @@ Same rules, applied recursively to all fields
 
 It is possible to override the initialization values by providing -- as in the earlier example of class <code>HELLO</code> -- one or more creation procedures. For example we might change <code>ACCOUNT</code> to make sure that every account is created with an initial deposit: 
 <code>
-indexing
+note
     description : "Simple bank accounts, initialized with a first deposit"
 
 class
@@ -289,6 +289,7 @@ instead of the usual
 <code>
             i + j
 
+
 </code>
 This would be awkward. Infix and prefix features solve the problem, reconciling the object-oriented view of computation with common notational practices of mathematics. The addition function is declared in class <code>INTEGER</code> as 
 <code>
@@ -345,7 +346,7 @@ the possible run-time values for <code> x </code> are references, which will be
 
 Instead of <code>class</code>, however, you may use the double keyword <code>expanded class</code> , as in the EiffelBase class definition 
 <code>
-indexing
+note
     description : "Integer values"
 
 expanded class
@@ -374,7 +375,7 @@ so that the values for <code>x</code> will be objects of type <code>C</code>, ra
 
 Note that the value of an entity of an expanded type can never be void; only a reference can. Extending the earlier terminology, an expanded entity is always '''attached to''' an object, atomic (as in the case of <code>n: INTEGER</code> ) or composite (as in <code>x: expanded ACCOUNT</code>). 
 
-Expanded declarations make it possible to construct composite objects with subobjects, as in the following abbreviated class declaration (indexing clause and routines omitted):
+Expanded declarations make it possible to construct composite objects with subobjects, as in the following abbreviated class declaration (<code>note</code> clause and routines omitted):
 <code>
 class CAR
 

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

@@ -8,7 +8,7 @@ Inheritance is a powerful and attractive technique. A look at either the practic
 
 To make a class inherit from another, simply use an <code>inherit</code> clause: 
 <code>
-indexing ...
+note ...
 
 class 
     D
@@ -36,7 +36,7 @@ Assume a class <code>SAVINGS_ACCOUNT</code> that specializes the notion of accou
 
 This example is typical of the form of reuse promoted by inheritance and crucial to effective reusability in software: the case of reuse with adaptation. Traditional forms of reuse are all-or-nothing: either you take a component exactly as it is, or you build your own. Inheritance will get us out of this "reuse or redo" dilemma by allowing us to reuse and redo. The mechanism is feature redefinition: 
 <code>
-indexing
+note
     description: "Savings accounts"
 
 class
@@ -179,7 +179,7 @@ It is also useful to define classes that leave the implementation of some of the
 
 At the level of the deferred class <code>LIST</code>, some features such as <code>extend</code> (add an item at the end of the list) will have no implementation and hence will be declared as deferred. Here is the corresponding form, illustrating the syntax for both deferred classes and their deferred features: 
 <code>
-indexing
+note
     description: "[
         Sequential finite lists, without a commitment
         to a representation."
@@ -278,7 +278,7 @@ The following sketch (from the book [http://eiffel.com/doc/oosc/ Object-Oriented
 
 Note the use of assertions to define semantic properties of the class, its instances and its features. Although often presented as high-level, most object-oriented analysis methods (with the exception of Walden's and Nerson's Business Object Notation) have no support for the expression of such properties, limiting themselves instead to the description of broad structural relationships. 
 <code>
-indexing
+note
     description: "Individual fragments of a broadcasting schedule"
 
 deferred class
@@ -347,7 +347,7 @@ For such classes it is again essential to permit effective features in a deferre
 
 {{note|The type <code>like Current</code> will be explained in [[9 Inheritance#Covariance_and_anchored_declarations|"Covariance and anchored declarations"]] ; you may understand it, in the following class, as equivalent to <code>COMPARABLE</code>. }}
 <code>
-indexing
+note
     description: "Objects that can be compared according to a total preorder relation"
 
 deferred class
@@ -398,7 +398,7 @@ In all such cases multiple inheritance provides the answer.
 
 Multiple inheritance can cause '''name clashes''' : two parents may include a feature with the same name. This would conflict with the ban on name overloading within a class -- the rule that no two features of a class may have the same name. Eiffel provides a simple way to remove the name clash at the point of inheritance through the <code>rename</code> subclause, as in 
 <code>
-indexing
+note
     description: "Sequential finite lists implemented as arrays"
 
 class