Updated to upcoming 23.09

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

documentation/trunk/eiffel/Tutorials/Mini-HowTo/Iterating-on-a-LIST.wiki

@@ -1,4 +1,4 @@
-[[Property:modification_date|Wed, 17 Apr 2019 14:09:18 GMT]]
+[[Property:modification_date|Tue, 24 Jan 2023 15:15:39 GMT]]
 [[Property:publication_date|Thu, 06 Sep 2018 15:17:57 GMT]]
 [[Property:uuid|96077603-DD2D-4D8C-A486-AF4BD066613A]]
 [[Property:weight|2000]]
@@ -39,7 +39,7 @@ This syntax offer more possibilities than the `across` loop, but is riskier.
 </code>
 
 === Using Eiffel agents and `{LIST}.do_all, ....` ===
-It is possible to use agents in conjunction with the `LIST` features `do_all`, `do_if`, `there_exists`, and `for_all` which are inherited from the class `LINEAR`.
+It is possible to use  [[ET-_Agents|agents]] in conjunction with the `LIST` features `do_all`, `do_if`, `there_exists`, and `for_all` which are inherited from the class `LINEAR`.
 <code>
 	list_traversal_agents
 			-- Example of traversing a list with do_all

documentation/trunk/eiffel/Tutorials/eiffel-tutorial-et/et-design-contract-tm-assertions-and-exceptions.wiki

@@ -1,4 +1,4 @@
-[[Property:modification_date|Thu, 21 Jan 2021 13:42:09 GMT]]
+[[Property:modification_date|Mon, 23 Jan 2023 09:17:43 GMT]]
 [[Property:publication_date|Thu, 21 Jan 2021 13:42:09 GMT]]
 [[Property:title|ET: Design by Contract (tm), Assertions and Exceptions]]
 [[Property:weight|-8]]
@@ -116,9 +116,9 @@ Use a non-negative argument.
 Get deposits list and balance updated. 
 |- 
 |   '''Supplier''' 
-|  (Satisfy precondition:) <br/>
-Update deposits list and balance. 
 |  (From postcondition:) <br/>
+Update deposits list and balance. 
+|  (Satisfy precondition:) <br/>
 No need to handle negative arguments. 
 |}
 
@@ -322,7 +322,7 @@ Concretely, exceptions may result from the following events: <br/>
 *  Assertion violation, if for a system that runs with assertion monitoring on. 
 *  Attempt to call a feature on a void reference: <code>x.f (...)</code>, the fundamental computational mechanism, can only work if <code>x</code> is attached to an object, and will cause an exception otherwise. 
 *  Developer exception, as seen next. 
-*  Operating system signal:arithmetic overfolow; no memory available for a requested creation or twin -- even after garbage collection has rummaged everything to find some space. (But no C/C++-like "wrong pointer address", which cannot occur thanks to the statically typed nature of Eiffel.)
+*  Operating system signal:arithmetic overflow; no memory available for a requested creation or twin -- even after garbage collection has rummaged everything to find some space. (But no C/C++-like "wrong pointer address", which cannot occur thanks to the statically typed nature of Eiffel.)
 
 
 It is sometimes useful, when handling exceptions in <code>rescue</code> clauses, to ascertain the exact nature of the exception that got the execution there. For this it suffices to inherit from the Kernel Library class <code>EXCEPTIONS</code>, which provides queries such as <code>exception</code>, giving the code for the last exception, and symbolic names ( [[ET: Other Mechanisms#Constant_attributes|"Constant attributes"]] ) for all such codes, such as <code>No_more_memory</code>. You can then process different exceptions differently by testing <code>exception</code> against various possibilities. The method strongly suggests, however, that exception handling code should remain simple; a complicated algorithm in a <code>rescue</code> clause is usually a sign that the mechanism is being misused. Class <code>EXCEPTIONS</code> also provides various facilities for fine-tuning the exception facilities, such as a procedure <code>raise</code> that will explicitly trigger a "developer exception" with a code that can then be detected and processed. Exception handling helps produce Eiffel software that is not just correct but robust, by planning for cases that should not normally arise, but might out of Murphy's law, and ensuring they do not affect the software's basic safety and simplicity. 

documentation/trunk/eiffel/Tutorials/eiffel-tutorial-et/et-dynamic-structure-execution-model.wiki

@@ -1,3 +1,5 @@
+[[Property:modification_date|Mon, 23 Jan 2023 09:14:48 GMT]]
+[[Property:publication_date|Mon, 23 Jan 2023 09:14:48 GMT]]
 [[Property:title|ET: The Dynamic Structure: Execution Model]]
 [[Property:weight|-10]]
 [[Property:uuid|1f3f2707-9129-4dca-76c7-157143d7ae74]]
@@ -7,7 +9,7 @@ The properties of the run-time model are not just of interest to implementers; t
 
 ==Objects, fields, values, and references==
 
-A class was defined as the static description of a type of run-time data structures. The data structures described by a ca class are called '''instances''' of the class, which in turn is called their '''generating class''' (or just "generator"). An instance of <code>ACCOUNT</code> is a data structure representing a bank account; an instance of <code>LINKED_LIST</code> is a data structure representing a linked list. 
+A class was defined as the static description of a type of run-time data structures. The data structures described by a class are called '''instances''' of the class, which in turn is called their '''generating class''' (or just "generator"). An instance of <code>ACCOUNT</code> is a data structure representing a bank account; an instance of <code>LINKED_LIST</code> is a data structure representing a linked list. 
 
 An '''object''', as may be created during the execution of a system, is an instance of some class of the system. 
 
@@ -146,7 +148,7 @@ False
 
 | &nbsp;
 | 
-Null
+NUL
 
 |- 
 | 

documentation/trunk/eiffel/Tutorials/eiffel-tutorial-et/et-general-properties.wiki

@@ -1,3 +1,5 @@
+[[Property:modification_date|Mon, 23 Jan 2023 09:06:45 GMT]]
+[[Property:publication_date|Mon, 23 Jan 2023 09:06:45 GMT]]
 [[Property:title|ET: General Properties]]
 [[Property:weight|-14]]
 [[Property:uuid|1ad0b1d5-7ac6-9f55-92ec-ba6f42aee690]]
@@ -40,7 +42,7 @@ It is also useful, as in any design, to list some of what is '''not''' present i
 *  ''No in-class overloading'', which by assigning the same name to different features within a single context, causes confusions, errors, and conflicts with object-oriented mechanisms such as dynamic binding. (Dynamic binding itself is a powerful form of inter-class overloading, without any of these dangers.) 
 *  ''No goto instructions'' or similar control structures (break, exit, multiple-exit loops) which break the simplicity of the control flow and make it harder or impossible to reason about the software (in particular through loop invariants and variants). 
 *  ''No exceptions to the type rules''. To be credible, a type system must not allow unchecked "casts" converting from a type to another. (Safe cast-like operations are available through object test.) 
-*  ''No side-effect expression operators'' confusing computation and modification. 
+*  ''No side-effect expression operators'' (such as `+=`) confusing computation and modification. 
 *  ''No low-level pointers, no pointer arithmetic'', a well-known source of bugs. (There is however a type ''POINTER'', used for interfacing Eiffel with C and other languages.) 
 
 

documentation/trunk/eiffel/Tutorials/eiffel-tutorial-et/et-software-process-eiffel.wiki

@@ -1,3 +1,5 @@
+[[Property:modification_date|Mon, 23 Jan 2023 09:10:19 GMT]]
+[[Property:publication_date|Mon, 23 Jan 2023 09:10:19 GMT]]
 [[Property:title|ET: The Software Process in Eiffel]]
 [[Property:weight|-13]]
 [[Property:uuid|eef7f31a-25de-93cc-9a33-41d991c51ccb]]
@@ -41,7 +43,7 @@ The last step of the cluster, Generalization, is unheard of in traditional model
 
 Recent object-oriented literature has used the term "refactoring" to describe a process of continuous improvement of released software. Generalization includes refactoring, but also pursues a more ambitious goal: helping turn program elements (software modules useful only as part of a certain program) into software components -- reusable parts with a value of their own, ready to be used by diverse programs that can benefit from their capabilities. 
 
-Of course not all companies using the method will be ready to include a Generalization phase in their. But those which do will see the reusability of their software greatly improved. 
+Of course not all companies using the method will be ready to include a Generalization phase in their process. But those which do will see the reusability of their software greatly improved. 
 
 ==Constant availability==
 

documentation/trunk/eiffel/Tutorials/eiffel-tutorial-et/et-static-picture-system-organization.wiki

@@ -1,3 +1,5 @@
+[[Property:modification_date|Mon, 23 Jan 2023 09:13:05 GMT]]
+[[Property:publication_date|Mon, 23 Jan 2023 09:13:05 GMT]]
 [[Property:title|ET: The Static Picture: System Organization]]
 [[Property:weight|-11]]
 [[Property:uuid|46d3f41e-d41c-a443-4574-403dfebb60aa]]
@@ -52,7 +54,8 @@ Any class that does not explicitly inherit from another is considered to inherit
 
 Classes are the only form of module in Eiffel. As will be explained in more detail, they also provide the basis for the only form of type. This module-type identification is at the heart of object technology and of the fundamental simplicity of the Eiffel method. 
 
-Above classes, you will find the concept of cluster. A cluster is a group of related classes. Clusters are a property of the method, enabling managers to organize the development into teams. As we have already seen (in [[ET: The Software Process in Eiffel|The Software Process in Eiffel]] ) they also play a central role in the lifecycle model. Clusters are an organizational concept, not a form of module, and do not require an Eiffel programming language construct. 
+Above classes, you will find the concept of cluster. A cluster is a collection of classes, (recursively) other clusters called its subclusters, or both. The
+cluster is said to contain directly these classes and subclusters.. Clusters are a property of the method, enabling managers to organize the development into teams. As we have already seen (in [[ET: The Software Process in Eiffel|The Software Process in Eiffel]] ) they also play a central role in the lifecycle model. Clusters are an organizational concept, not a form of module, and do not require an Eiffel programming language construct. 
 
 ==External software==
 

documentation/trunk/eiffel/Tutorials/eiffel-tutorial-et/index.wiki

@@ -1,6 +1,8 @@
+[[Property:modification_date|Mon, 23 Jan 2023 09:03:53 GMT]]
+[[Property:publication_date|Mon, 23 Jan 2023 09:03:53 GMT]]
 [[Property:title|An Eiffel Tutorial (ET)]]
 [[Property:link_title|Tutorial]]
 [[Property:weight|2]]
 [[Property:uuid|4dbc41e2-ecfc-8c50-9288-fce30f4abd90]]
-This Eiffel Tutorial (ET) should provide you with a broad understanding of what Eiffel is all about and why it is different from other technologies. Still more detail is available in [[Object-Oriented Software Construction, 2nd Edition]]. 
+This Eiffel Tutorial (ET) should provide you with a broad understanding of what Eiffel is all about and why it is different from other technologies. Still more detail is available in [[Object-Oriented Software Construction, 2nd Edition]]  and [[Touch of Class: Learning to Program Well with Objects and Contracts|Touch of Class]]. 
 

documentation/trunk/eiffel/Tutorials/invitation-eiffel-i2e/i2e-classes.wiki

@@ -1,3 +1,5 @@
+[[Property:modification_date|Mon, 23 Jan 2023 08:53:11 GMT]]
+[[Property:publication_date|Mon, 23 Jan 2023 08:51:31 GMT]]
 [[Property:title|I2E: Classes]]
 [[Property:weight|-11]]
 [[Property:uuid|218bead9-428e-f61d-1e45-7eea4291d895]]
@@ -40,7 +42,7 @@ These feature calls use dot notation, of the form <code>target_name.feature_name
 
 Routines are further divided into '''procedures''' (commands, which do not return a value) and '''functions''' (queries, returning a value). Here <code>may_withdraw</code> is a function returning a boolean; the other three-routines called are procedures. 
 
-{{info|A note on syntax: you may separate instructions by semicolons, and indeed you should when, as on the next-to-last line of the example, two or more instructions appear on a line. But the language's syntax has been designed so that the semicolon is almost always optional, regardless of the layout. Indeed the practice is to omit it between instructions or declarations on separate lines, as this results in lighter, clearer software texts. }}
+{{info|A note on syntax: you may separate instructions by semicolons, and indeed you should when, as on the next-to-last line of the example, two or more instructions appear on a line. But the language's syntax has been designed so that the semicolon is almost always optional, regardless of the layout. Indeed the practice is to omit it between instructions or declarations on separate lines, as this results in lighter, clearer software texts. Such as `acc.withdraw (3000); print (acc.balance)` }}
 
 In class <code>ACCOUNT</code>, is feature <code>balance</code> an attribute, or is it a function with no argument? The above extract of the client class <code>X</code> doesn't say, and this ambiguity is intentional. A client of <code>ACCOUNT</code> must not need to know how class <code>ACCOUNT</code> delivers an account's balance when requested: by looking up a field present in each account object, or by calling a function that computes the balance from other fields. Choosing between these techniques is the business of class <code>ACCOUNT</code>, not anybody else's. Because such implementation choices are often changed over the lifetime of a project, it is essential to protect clients against their effects. This is known as the '''Uniform Access Principle''', stating that the choice between representing a property through memory (an attribute) or through an algorithm (function) shall not affect how clients use it. 
 
@@ -92,7 +94,7 @@ end -- ACCOUNT
 
 Let us examine the features in sequence. The <code>do</code> <code>...</code> <code>end</code> distinguishes routines from attributes. So here the class has implemented <code>balance</code> as an attribute, although, as noted, a function would also have been acceptable. Feature <code>owner</code> is also an attribute. 
 
-The language definition guarantees automatic initialization, so that the initial balance of an account object will be zero after a creation instruction. Each type has a default initial value: zero for <code>INTEGER</code> and <code>REAL</code>, false for <code>BOOLEAN</code>, null character for <code>CHARACTER</code>, and a void reference for reference types. The class designer may also provide clients with different initialization options, as will be seen below in a revised version of this example. 
+The language definition guarantees automatic initialization, so that the initial balance of an account object will be zero after a creation instruction. Each type has a default initial value: zero for <code>INTEGER</code> and <code>REAL</code>, false for <code>BOOLEAN</code>, NUL character for <code>CHARACTER</code>, and a void reference for reference types. The class designer may also provide clients with different initialization options, as will be seen below in a revised version of this example. 
 
 The other public features, <code>withdraw, deposit, open,</code> and <code>may_withdraw</code> are straight-forward routines. The special entity <code>Result</code>, used in <code>may_withdraw</code>, denotes the function result; it is initialized on function entry to the default value of the function's result type. You may only use <code>Result</code> in functions. 
 

documentation/trunk/eiffel/Tutorials/invitation-eiffel-i2e/i2e-design-contract-and-assertions.wiki

@@ -1,3 +1,5 @@
+[[Property:modification_date|Mon, 23 Jan 2023 08:58:40 GMT]]
+[[Property:publication_date|Mon, 23 Jan 2023 08:58:40 GMT]]
 [[Property:title|I2E: Design by Contract and Assertions]]
 [[Property:weight|-9]]
 [[Property:uuid|f563aa75-3a5a-5110-b4f1-07da5448f668]]
@@ -133,7 +135,7 @@ feature
 end -- ACCOUNT
 </code>
 
-This is not actual Eiffel, only documentation of Eiffel classes, hence the use of slightly different syntax to avoid any confusion ( <code>interface class</code> rather than <code>class</code>). In accordance with the Uniform Access Principle (in [[I2E: Classes|Classes]]), the output for <code>balance</code> would be the same if this feature were a function rather than an attribute. 
+This is not actual Eiffel, only documentation of Eiffel classes, hence the use of slightly different syntax to avoid any confusion ( <code>class interface</code> rather than <code>class</code>). In accordance with the Uniform Access Principle (in [[I2E: Classes|Classes]]), the output for <code>balance</code> would be the same if this feature were a function rather than an attribute. 
 
 You will find in EiffelStudio automatic tools to produce the Contract Form of a class. You can also get the '''Flat Contract''' form, based on the same ideas but including inherited features along with those introduced in the class itself. EiffelStudio can produce these forms, and other documentation views of a class, in a variety of output formats including HTML, so that collaborative projects can automatically post the latest versions of their class interfaces on the Internet or an Intranet. 
 

documentation/trunk/eiffel/Tutorials/invitation-eiffel-i2e/i2e-inheritance.wiki

@@ -1,3 +1,5 @@
+[[Property:modification_date|Mon, 23 Jan 2023 09:00:46 GMT]]
+[[Property:publication_date|Mon, 23 Jan 2023 09:00:46 GMT]]
 [[Property:title|I2E: Inheritance]]
 [[Property:weight|-5]]
 [[Property:uuid|acf84989-0e7c-f2f7-427a-19e7fce404ce]]
@@ -9,8 +11,7 @@ class ARRAYED_LIST [G]
     inherit
         LIST [G]
         ARRAY [G]
-
-    export ... See below ... end
+            export ... See below ... end
 
 feature
     ... Specific features of fixed-size lists ...
@@ -32,8 +33,7 @@ class ARRAYED_LIST [G]
     inherit
         LIST [G]
         ARRAY [G]
-
-    export {NONE} all end
+            export {NONE} all end
 
     ... The rest as above ...
 </code>