diff --git a/documentation/current/method/eiffel-tutorial-et/et-dynamic-structure-execution-model.wiki b/documentation/current/method/eiffel-tutorial-et/et-dynamic-structure-execution-model.wiki index 5ba29772..714d4ca9 100644 --- a/documentation/current/method/eiffel-tutorial-et/et-dynamic-structure-execution-model.wiki +++ b/documentation/current/method/eiffel-tutorial-et/et-dynamic-structure-execution-model.wiki @@ -195,49 +195,49 @@ A create clause may list zero or more (here just one) procedures of {{info|Note the use of the same keyword, create , for both a creation clause, as here, and creation instructions such as create x . }} -In this case the original form of creation instruction, create x , is not valid any more for creating an instance of ACCOUNT1 ; you must use the form +In this case the original form of creation instruction, create x , is not valid any more for creating an instance of ACCOUNT1; you must use the form create x.make (2000) -known as a creation call. Such a creation call will have the same effect as the original form -- creation, initialization, attachment to -- x followed by the effect of calling the selected creation procedure, which here will call deposit with the given argument. +known as a creation call. Such a creation call will have the same effect as the original form -- creation, initialization, attachment to -- x followed by the effect of calling the selected creation procedure, which here will call deposit with the given argument. -Note that in this example all that make does is to call deposit . So an alternative to introducing a new procedure make would have been simply to introduce a creation clause of the form create deposit , elevating deposit to the status of creation procedure. Then a creation call would be of the form create x.deposit (2000) . +Note that in this example all that make does is to call deposit. So an alternative to introducing a new procedure make would have been simply to introduce a creation clause of the form create deposit , elevating deposit to the status of creation procedure. Then a creation call would be of the form create x.deposit (2000) . {{info|Some variants of the basic creation instruction will be reviewed later: instruction with an explicit type; creation expressions. See [[10 Other Mechanisms#Creation_variants|"Creation variants"]] . }} ==Entities== -The example assumed x declared of type ACCOUNT (or ACCOUNT1 ). Such an x is an example of '''entity''', a notion generalizing the well-known concept of variable. An entity is a name that appears in a class text to represent possible run-time values (a value being, as defined earlier, an object or a reference). An entity is one of the following:
-* An attribute of the enclosing class, such as balance and all_deposits . -* A formal argument of a routine, such as sum for deposit and make . +The example assumed x declared of type ACCOUNT (or ACCOUNT1). Such an x is an example of '''entity''', a notion generalizing the well-known concept of variable. An entity is a name that appears in a class text to represent possible run-time values (a value being, as defined earlier, an object or a reference). An entity is one of the following:
+* An attribute of the enclosing class, such as balance and all_deposits. +* A formal argument of a routine, such as sum for deposit and make. * A local entity declared for the internal needs of a routine. -* The special entity Result in a function. +* The special entity Result in a function. The third case, local entities, arises when a routine needs some auxiliary values for its computation. Here is an example of the syntax: deposit (sum: INTEGER) - -- Add sum to account. - local - new: AMOUNT - do - create new.make (sum) - all_deposits.extend (new) - balance := balance + sum - end + -- Add sum to account. + local + new: AMOUNT + do + create new.make (sum) + all_deposits.extend (new) + balance := balance + sum + end -This example is a variant of deposit for which we assume that the elements of a DEPOSIT_LIST such as all_deposits are no longer just integers, but objects, instances of a new class, AMOUNT . Such an object will contain an integer value, but possibly other information as well. So for the purpose of procedure deposit we create an instance of AMOUNT and insert it, using procedure extend , into the list all_deposits . The object is identified through the local entity new , which is only needed within each execution of the routine (as opposed to an attribute, which yields an object field that will remain in existence for as long as the object). +This example is a variant of deposit for which we assume that the elements of a DEPOSIT_LIST such as all_deposits are no longer just integers, but objects, instances of a new class, AMOUNT. Such an object will contain an integer value, but possibly other information as well. So for the purpose of procedure deposit we create an instance of AMOUNT and insert it, using procedure extend, into the list all_deposits. The object is identified through the local entity new, which is only needed within each execution of the routine (as opposed to an attribute, which yields an object field that will remain in existence for as long as the object). -The last case of entity, Result , serves to denote, within the body of a function, the final result to be returned by that function. This was illustrated by the function deposit_count , which read +The last case of entity, Result, serves to denote, within the body of a function, the final result to be returned by that function. This was illustrated by the function deposit_count, which read deposit_count: INTEGER - -- Number of deposits made since opening (provisional version) - do - if all_deposits /= Void then - Result := all_deposits.count - end - end + -- Number of deposits made since opening (provisional version) + do + if all_deposits /= Void then + Result := all_deposits.count + end + end The value returned by any call will be the value of the expression all_deposits.count (to be explained in detail shortly) for that call, unless all_deposits /code> is a Void reference ( /= means "not equal"). @@ -268,9 +268,9 @@ Following the principle of Uniform Access (mentioned earlier in the section ''Ob In the case of a routine with arguments -- procedure or function -- the routine will be declared, in its class, as feature (formal1: TYPE1; ...) - do - ... - end + do + ... + end meaning that, at the time of each call, the value of each formal will be set to the corresponding actual ( formal1 to argument1 and so on). @@ -279,21 +279,21 @@ In the routine body, it is not permitted to change the value of a formal argumen ==Infix and prefix notation== -Basic types such as INTEGER are, as noted, full-status citizens of Eiffel's type system, and so are declared as classes (part of the Kernel Library). INTEGER , for example, is characterized by the features describing integer operations: plus, minus, times, division, less than, and so on. +Basic types such as INTEGER are, as noted, full-status citizens of Eiffel's type system, and so are declared as classes (part of the Kernel Library). INTEGER, for example, is characterized by the features describing integer operations: plus, minus, times, division, less than, and so on. -With the dot notation seen so far, this would imply that simple arithmetic operations would have to be written with a syntax such as i.plus (j) instead of the usual i + j . 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 INTEGER as +With the dot notation seen so far, this would imply that simple arithmetic operations would have to be written with a syntax such as i.plus (j) instead of the usual i + j. 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 INTEGER as infix "+" (other: INTEGER): INTEGER - do - ... - end + do + ... + end -Such a feature has all the properties and prerogatives of a normal "identifier" feature, except for the form of the calls, which is infix, as in i + j , rather than using dot notation. An infix feature must be a function, and take exactly one argument. Similarly, a function can be declared as prefix "-" , with no argument, permitting calls of the form -3 rather than (3).negated . +Such a feature has all the properties and prerogatives of a normal "identifier" feature, except for the form of the calls, which is infix, as in i + j , rather than using dot notation. An infix feature must be a function, and take exactly one argument. Similarly, a function can be declared as prefix "-" , with no argument, permitting calls of the form -3 rather than (3).negated . -Predefined library classes covering basic types such as INTEGER, CHARACTER, BOOLEAN, REAL, DOUBLE are known to the Eiffel compiler, so that a call of the form j + i , although conceptually equivalent to a routine call, can be processed just as efficiently as the corresponding arithmetic expression in an ordinary programming language. This brings the best of both worlds: conceptual simplicity, enabling Eiffel developers, when they want to, to think of integers and the like as objects; and efficiency as good as in lower-level approaches. +Predefined library classes covering basic types such as INTEGER, CHARACTER, BOOLEAN, REAL, DOUBLE are known to the Eiffel compiler, so that a call of the form , although conceptually equivalent to a routine call, can be processed just as efficiently as the corresponding arithmetic expression in an ordinary programming language. This brings the best of both worlds: conceptual simplicity, enabling Eiffel developers, when they want to, to think of integers and the like as objects; and efficiency as good as in lower-level approaches. -Infix and prefix features are available to any class, not just the basic types' predefined classes. For example a graphics class could use the name infix "|-|" for a function computing the distance between two points, to be used in expressions such as point1 |-| point2 . +Infix and prefix features are available to any class, not just the basic types' predefined classes. For example a graphics class could use the name infix "|-|" for a function computing the distance between two points, to be used in expressions such as point1 |-| point2 . ==Type declaration== @@ -307,9 +307,9 @@ This applies to attributes, formal arguments of routines and local entities. You deposit_count: INTEGER ... -Specifying such a function result type also declares, implicitly, the type for Result as used in the function's body. +Specifying such a function result type also declares, implicitly, the type for Result as used in the function's body. -What is a type? With the elements seen so far, every type is a class . INTEGER, used in the declaration of deposits_count, is, as we have seen, a library class; and the declaration all_deposits : DEPOSIT_LIST assumes the existence of a class DEPOSIT_LIST . +What is a type? With the elements seen so far, every type is a class . INTEGER, used in the declaration of deposits_count, is, as we have seen, a library class; and the declaration all_deposits: DEPOSIT_LIST assumes the existence of a class DEPOSIT_LIST . Three mechanisms introduced below -- expanded types, genericity, and anchored declarations -- will generalize the notion of type slightly. But they do not change the fundamental property that '''every type is based on a class''', called the type's '''base class'''. In the examples seen so far, each type is a class, serving as its own base class. @@ -329,29 +329,29 @@ it defines a reference type. The entities declared of that type will denote refe x: ACCOUNT -the possible run-time values for x are references, which will be either void or attached to instances of class ACCOUNT . +the possible run-time values for x are references, which will be either void or attached to instances of class ACCOUNT . Instead of class, however, you may use the double keyword expanded class , as in the EiffelBase class definition indexing - description : "Integer values" + description : "Integer values" expanded class - INTEGER + INTEGER feature -- Basic operations - infix "+" (other: INTEGER): INTEGER - do - ... - end + infix "+" (other: INTEGER): INTEGER + do + ... + end - ... Other feature declarations ... + ... Other feature declarations ... end -- class INTEGER -In this case the value of an entity declared as n:INTEGER is not a reference to an object, but the object itself -- in this case an atomic object, an integer value. +In this case the value of an entity declared as n: INTEGER is not a reference to an object, but the object itself -- in this case an atomic object, an integer value. It is also possible, for some non-expanded class C, to declare an entity as @@ -368,24 +368,24 @@ class CAR feature - engine: expanded ENGINE + engine: expanded ENGINE - originating_plant: PLANT + originating_plant: PLANT end -- class CAR -Here is an illustration of the structure of a typical instance of CAR : +Here is an illustration of the structure of a typical instance of CAR: [[Image:tutorial-8]] -This example also illustrates that the distinction between expanded and reference types is important not just for system implementation purposes but for high-level system modeling as well. Consider the example of a class covering the notion of car. Many cars share the same originating_plant , but an engine belongs to just one car. References represent the modeling relation "knows about"; subobjects, as permitted by expanded types, represent the relation "has part", also known as aggregation. The key difference is that sharing is possible in the former case but not in the latter. +This example also illustrates that the distinction between expanded and reference types is important not just for system implementation purposes but for high-level system modeling as well. Consider the example of a class covering the notion of car. Many cars share the same originating_plant, but an engine belongs to just one car. References represent the modeling relation "knows about"; subobjects, as permitted by expanded types, represent the relation "has part", also known as aggregation. The key difference is that sharing is possible in the former case but not in the latter. ==Basic operations== -To assign, copy and compare values, you can rely on a number of mechanisms. Two of them, assignment and equality testing, are language constructs; the others are library features, coming from the top-level class ANY seen earlier (page [[5 The Static Picture: System Organization|15]] ). +To assign, copy and compare values, you can rely on a number of mechanisms. Two of them, assignment and equality testing, are language constructs; the others are library features, coming from the top-level class ANY seen earlier (page [[5 The Static Picture: System Organization|15]] ). Assignment uses the symbol := . The assignment instruction @@ -398,7 +398,7 @@ updates the value of x to be the same as that of y. Th [[Image:tutorial-9]] -For entities of reference types, the value of x will be a void reference if the value of y is void, and otherwise x will be attached to the same object OBJ2 as y : +For entities of reference types, the value of x will be a void reference if the value of y is void, and otherwise x will be attached to the same object OBJ2 as y: [[Image:tutorial-9]]