Author:halw

Date:2008-09-28T19:35:05.000000Z


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

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

@@ -11,15 +11,15 @@ A system -- a software system in particular, but the ideas are more general -- i
 An Eiffel contract is similar to a real-life contract between two people or two companies, which it is convenient to express in the form of tables listing the expectations and guarantees. Here for example is how we could sketch the contract between a homeowner and the telephone company:
 {| border="1"
 |- 
-| <code>provide_service</code>|| style="width=10%"
-| '''OBLIGATIONS'''|| style="width=35%"
-| '''BENEFITS'''|| style="width=35%"
+| style="width=10%" |provide telephone service 
+| style="width=35%" |'''OBLIGATIONS'''
+| style="width=35%" |'''BENEFITS'''
 |- 
 |   '''Client''' 
 |  (Satisfy precondition:) <br/>
 Pay bill. 
 |  (From postcondition:) <br/>
-Get telephone service Supplier. 
+Receive telephone service from Supplier. 
 |- 
 |   '''Supplier''' 
 |  (Satisfy precondition:) <br/>
@@ -95,9 +95,9 @@ The postcondition of a routine expresses what the routine guaranteed to its clie
 The precondition and postcondition state the terms of the contract between the routine and its clients, similar to the earlier example of a human contract:
 {| border="1"
 |- 
-| <code>deposit</code>|| style="width=10%;"
-| '''OBLIGATIONS'''|| style="width=35%;"
-| '''BENEFITS'''|| style="width=35%;"
+| style="width=10%" |<code>deposit</code>
+| style="width=35%"| '''OBLIGATIONS'''
+| style="width=35%" | '''BENEFITS'''
 |- 
 |   '''Client''' 
 |  (Satisfy precondition:) <br/>

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

@@ -78,7 +78,7 @@ The inheritance mechanism is relevant to both roles of classes: module and type.
 
 '''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). 
 
-{{note|In addition, it follows from the earlier discussion of tuples ( [[10 Other Mechanisms|"Tuple types", page 90]] ), that <code> TUPLE [X] </code> conforms to <code> TUPLE </code>, <code> TUPLE [X, Y] </code> to <code> TUPLE [X] </code> and so on. }}
+{{note|In addition, it will be shown in the discussion of tuples ([[10 Other Mechanisms|"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. }}
 
 So with the inheritance structure that we have seen, the declarations
 <code>
@@ -580,10 +580,7 @@ If there are separate accounts for students' course work and for faculty, you ma
 
 The Eiffel rule enables, once again, the software developer to craft the resulting class so as to tune it to the exact requirements. Not surprisingly, it is based on names, in accordance with the Final Name rule (no in-class overloading):
 
-{{note| '''Repeated Inheritance rule''' <br/>
-* A feature inherited multiply under one name will be shared: it is considered to be just one feature in the repeated descendant. 
-* A feature inherited multiply under different names will be replicated, yielding as many variants as names. 
-}}
+{{note| '''Repeated Inheritance rule:''' <br/>A feature inherited multiply under one name will be shared: it is considered to be just one feature in the repeated descendant.<br/>A feature inherited multiply under different names will be replicated, yielding as many variants as names. }}
 
 So to tune the repeated descendant, feature by feature, for sharing and replication it suffices to use renaming. 
 

documentation/current/method/eiffel-tutorial-et/et-lexical-conventions-and-style-rules.wiki

@@ -6,7 +6,7 @@ Eiffel software texts are free-format: distribution into lines is not semantical
 
 Successive declarations or instructions may be separated by semicolons. Eiffel's syntax has been so designed, however, that (except in rare cases) '''the semicolon is optional'''. Omitting semicolons for elements appearing on separate lines lightens text and is the recommended practice since semicolons, as used by most programming languages, just obscure the text by distracting attention from the actual contents. Do use semicolons if you occasionally include successive elements on a single line. 
 
-63 names -- all unabbreviated single English words, except for <code> elseif </code> which is made of two words -- are reserved, meaning that you cannot use them to declare new entities. Here is the list: 
+56 names -- all unabbreviated single English words, except for <code> elseif </code> which is made of two words -- are reserved, meaning that you cannot use them to declare new entities. Here is the list: 
 {| border="1"
 |- 
 | <code>agent</code>