Author:halw

Date:2008-10-23T14:51:56.000000Z


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

documentation/current/method/eiffel-tutorial-et/et-genericity-and-arrays.wiki

@@ -27,7 +27,7 @@ Within the class text, feature declarations can freely use <code>G</code> even t
         ...
 </code>
 
-The operations available on an entity such as <code>first</code> and <code>val</code>, whose type is a formal generic parameter, are the operations available on all types: use as source <code>y</code> of an assignment <code>x := y</code>, use as target <code>x</code> of such an assignment (although not for <code>val</code>, which as a formal routine argument is not writable), use in equality comparisons <code>x = y</code> or <code>x /= y</code>, and application of universal features from <code>ANY</code> such as <code>clone</code>, <code>equal</code> and <code>copy</code>. 
+The operations available on an entity such as <code>first</code> and <code>val</code>, whose type is a formal generic parameter, are the operations available on all types: use as source <code>y</code> of an assignment <code>x := y</code>, use as target <code>x</code> of such an assignment (although not for <code>val</code>, which as a formal routine argument is not writable), use in equality comparisons <code>x = y</code> or <code>x /= y</code>, and application of universal features from <code>ANY</code> such as <code>twin</code>, <code>is_equal</code> and <code>copy</code>. 
 
 To use a generic class such as list, a client will provide a type name as '''actual generic parameter'''. So instead of relying on a special purpose class <code>DEPOSIT_LIST</code>, the class <code>ACCOUNT</code> could include the declaration 
 <code>all_deposits: LIST [DEPOSIT]</code>

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

@@ -7,6 +7,8 @@ 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. 
 
 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>
@@ -74,6 +76,7 @@ Successive declarations or instructions may be separated by semicolons. Eiffel's
 | <code>undefine</code>
 |}
 
+
 Since this tutorial has covered all the essential mechanisms, you may ignore the keywords not encountered; they are reserved for future use. 
 
 Most of the reserved words are keywords, serving only as syntactic markers, and written in boldface in typeset texts such as the present one: <code>class</code>, <code>feature</code>, <code>inherit</code>. The others, such as <code>Current</code>, directly carry a semantic denotation; they start with an upper-case letter and are typeset in boldface. 

documentation/current/method/eiffel-tutorial-et/et-other-mechanisms.wiki

@@ -38,7 +38,7 @@ The attributes studied earlier were variable: each represents a field present in
 
 It is also possible to declare constant attributes, as in
 <code>
-        Solar_system_planet_count: INTEGER = 9
+    Solar_system_planet_count: INTEGER = 9
 </code>
 
 These will have the same value for every instance and hence do not need to occupy any space in objects at execution time. (In other approaches similar needs would be addressed by symbolic constants, as in Pascal or Ada, or macros, as in C.)
@@ -47,12 +47,12 @@ What comes after the <code>=</code> is a manifest constant: a self-denoting valu
 
 Manifest constants are also available for strings, using double quotes as in
 <code>
-        User_friendly_error_message: STRING is "Go get a life !"
+    User_friendly_error_message: STRING = "Go get a life !"
 </code>
 
 with special characters again using the <code>%</code> codes. It is also possible to declare manifest arrays using double angle brackets: 
 <code>
-            <<1, 2, 3, 5, 7, 11, 13, 17, 19>>
+                <<1, 2, 3, 5, 7, 11, 13, 17, 19>>
 </code>
 
 which is an expression of type <code>ARRAY [INTEGER]</code>. Manifest arrays and strings are not atomic, but denote instances of the Kernel Library classes <code>STRING</code> and <code>ARRAY</code>, as can be produced by once functions. 
@@ -87,7 +87,7 @@ A multi-branch instruction has the form
             end
 </code>
 
-where the <code>else ''inst0''</code> part is optional, <code>exp</code> is a character or integer expression, ''v1'', ''v1'', ... are constant values of the same type as <code>exp</code>, all different, and ''inst0'', ''inst1'', ''inst2'', ... are sequences of zero or more instructions. In the integer case, it is often convenient to use <code>unique</code> values ( [[10 Other Mechanisms|"Constant and unique attributes", page 83]] ) for the ''vi''.
+where the <code>else ''inst0''</code> part is optional, <code>exp</code> is a character or integer expression, ''v1'', ''v1'', ... are constant values of the same type as <code>exp</code>, all different, and ''inst0'', ''inst1'', ''inst2'', ... are sequences of zero or more instructions. 
 
 The effect of such a multi-branch instruction, if the value of <code>exp</code> is one of the ''vi'', is to execute the corresponding ''insti''. If none of the ''vi'' matches, the instruction executes ''inst0'', unless there is no <code>else</code> part, in which case it triggers an exception. 
 
@@ -188,7 +188,7 @@ The design flexibility afforded by the <code>obsolete</code> keyword is critical
 
 ==Creation variants==
 
-The basic forms of creation instruction, and the one most commonly used, are the two illustrated earlier ( [[6 The Dynamic Structure: Execution Model|"Creating and initializing objects", page 20]] ): 
+The basic forms of creation instruction, and the one most commonly used, are the two illustrated earlier ( [[6 The Dynamic Structure: Execution Model#Creating_and_initializing_objects|"Creating and initializing objects"]] ): 
 <code>
             create x.make (2000)
             create x