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/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>