mirrors/eiffel-org
1
0
Fork 0
mirror of https://github.com/EiffelSoftware/eiffel-org.git synced 2025-12-08 15:52:26 +01:00
Code Issues Packages Projects Releases Wiki Activity

Author:halw

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


git-svn-id: https://svn.eiffel.com/eiffel-org/trunk@173 abb3cda0-5349-4a8f-a601-0c33ac3a8c38
This commit is contained in:
halw
2009-01-28 16:53:41 +00:00
parent 2e66b008a7
commit 0b74232240
62 changed files with 276 additions and 185 deletions
Download Patch File Download Diff File Expand all files Collapse all files

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

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