diff --git a/documentation/current/eiffelstudio/eiffelstudio-guided-tour/viewing-classes.wiki b/documentation/current/eiffelstudio/eiffelstudio-guided-tour/viewing-classes.wiki index 125b9f3b..3e97dd89 100644 --- a/documentation/current/eiffelstudio/eiffelstudio-guided-tour/viewing-classes.wiki +++ b/documentation/current/eiffelstudio/eiffelstudio-guided-tour/viewing-classes.wiki @@ -48,7 +48,7 @@ Let's now look at the other formats, starting from the left. The first button, < This view is called "clickable" because, as we'll see later, every syntactical element on it is a hyperlink, which you can use for browsing. -After Clickable comes the Flat view button. The layout of the result is similar. The flat form of a class is the reconstructed class text including not only what's declared in the class itself but also everything that it inherits from its ancestors, direct or indirect. This applies to the flat form's features, which include ancestor features, but also to contracts: the flat form's invariant includes all clauses from ancestors' invariants, and the preconditions are expanded to take require else and ensure then clauses into consideration. (The [[An Eiffel Tutorial|Eiffel Tutorial]] explains these notions in detail.) +After Clickable comes the Flat view button. The layout of the result is similar. The flat form of a class is the reconstructed class text including not only what's declared in the class itself but also everything that it inherits from its ancestors, direct or indirect. This applies to the flat form's features, which include ancestor features, but also to contracts: the flat form's invariant includes all clauses from ancestors' invariants, and the preconditions are expanded to take require else and ensure then clauses into consideration. (The [[An Eiffel Tutorial (ET)|Eiffel Tutorial]] explains these notions in detail.) As a result, the Flat view shows the class text as it might have come out had inheritance (what a horrible thought even to contemplate!) not been available to write it. diff --git a/documentation/current/eiffelstudio/eiffelstudio-reference/compiler/differences-between-etl-2nd-printing-and-eiffel-software-implementation.wiki b/documentation/current/eiffelstudio/eiffelstudio-reference/compiler/differences-between-etl-2nd-printing-and-eiffel-software-implementation.wiki index d245582d..e5ad1c55 100644 --- a/documentation/current/eiffelstudio/eiffelstudio-reference/compiler/differences-between-etl-2nd-printing-and-eiffel-software-implementation.wiki +++ b/documentation/current/eiffelstudio/eiffelstudio-reference/compiler/differences-between-etl-2nd-printing-and-eiffel-software-implementation.wiki @@ -2,7 +2,10 @@ [[Property:link_title|]] [[Property:weight|-9]] [[Property:uuid|fc1e73f4-5646-aa41-e7fe-97dc6f3ceb04]] -{{seealso|[[Differences between standard ECMA-367 and Eiffel Software implementation|Differences between standard ECMA-367 and Eiffel Software implementation]] }} +{{seealso|See also: [[Differences between standard ECMA-367 and Eiffel Software implementation|Differences between standard ECMA-367 and Eiffel Software implementation]] }} + +==Added classes== +* New basic classes have been added: INTEGER_8, INTEGER_16, INTEGER_64 and WIDE_CHARACTER.{{seealso|[[Differences between standard ECMA-367 and Eiffel Software implementation|Differences between standard ECMA-367 and Eiffel Software implementation]] }} ==Added classes== * New basic classes have been added: INTEGER_8, INTEGER_16, INTEGER_64 and WIDE_CHARACTER. INTEGER is now specified as having a 32 bits representation @@ -33,7 +36,7 @@ ==Added semantics== -* [[7 Genericity and Arrays|Generic creation]] +* [[ET: Genericity and Arrays|Generic creation]] * Expression creation: you can now create an object within an expression. For example, you want to create an object and pass it as an argument to a function. Whereas you had to create a local variable, create the object and pass it to the function, you now simply need to pass to the function the creation expression. Here is a small example: {| |- @@ -60,8 +63,8 @@ end |} This is also very useful since it can improve the power of assertions. * Mutually recursive constraints: one can now write class A [H, G->H] or class B [H -> C, G -> ARRAY [H]]. As a result, the declaration A [D, E] is valid only if E is a descendant of D. Similarly, the declaration B [E, ARRAY [D]] is not valid, if E is a descendant of D. -* [[10 Other Mechanisms|Tuples]] -* [[11 Agents|Agents]] +* [[ET: Other Mechanisms|Tuples]] +* [[ET: Agents|Agents]] * Feature access:
local diff --git a/documentation/current/eiffelstudio/eiffelstudio-reference/compiler/differences-between-standard-ecma-367-and-eiffel-software-implementation.wiki b/documentation/current/eiffelstudio/eiffelstudio-reference/compiler/differences-between-standard-ecma-367-and-eiffel-software-implementation.wiki index 1b364149..44fba14c 100644 --- a/documentation/current/eiffelstudio/eiffelstudio-reference/compiler/differences-between-standard-ecma-367-and-eiffel-software-implementation.wiki +++ b/documentation/current/eiffelstudio/eiffelstudio-reference/compiler/differences-between-standard-ecma-367-and-eiffel-software-implementation.wiki @@ -118,7 +118,7 @@ | Yes | Yes |- -| [[7 Genericity and Arrays|Generic creation]] +| [[ET: Genericity and Arrays|Generic creation]] | create {G} x.make | No | Yes @@ -244,13 +244,13 @@ | Yes | Yes |- -| Manifest [[10 Other Mechanisms|tuple]] +| Manifest [[ET: Other Mechanisms|tuple]] | [a, b, c] | No | Yes | Yes |- -| [[11 Agents|Agent]] +| [[ET: Agents|Agent]] | list.do_all (agent print (?)) | No | Yes diff --git a/documentation/current/method/_images/VoidSafePrecompileOffer.png b/documentation/current/method/_images/VoidSafePrecompileOffer.png new file mode 100644 index 00000000..d0c2739e Binary files /dev/null and b/documentation/current/method/_images/VoidSafePrecompileOffer.png differ diff --git a/documentation/current/method/_images/VoidSafePrecompileOffer.png.data b/documentation/current/method/_images/VoidSafePrecompileOffer.png.data new file mode 100644 index 00000000..a559422c --- /dev/null +++ b/documentation/current/method/_images/VoidSafePrecompileOffer.png.data @@ -0,0 +1,3 @@ +title=VoidSafePrecompileOffer +author=halw +path=content/voidsafeprecompileoffer diff --git a/documentation/current/method/eiffel-tutorial-et/et-agents.wiki b/documentation/current/method/eiffel-tutorial-et/et-agents.wiki index 93c238f6..36290376 100644 --- a/documentation/current/method/eiffel-tutorial-et/et-agents.wiki +++ b/documentation/current/method/eiffel-tutorial-et/et-agents.wiki @@ -1,5 +1,4 @@ -[[Property:title|11 Agents]] -[[Property:link_title|ET: Agents]] +[[Property:title|ET: Agents]] [[Property:weight|-3]] [[Property:uuid|ba49a80d-5ddf-8b30-4943-528974fd0ddd]] Our last mechanism, agents, adds one final level of expressive power to the framework describe so far. Agents apply object-oriented concepts to the modeling of operations. @@ -80,7 +79,7 @@ Function integral takes three arguments: the agent f r Result := Result + step * f.item ([x]) -we don't directly pass x to item; instead, we pass a one-element tuple [x], using the syntax for manifest tuples introduced in [[10 Other Mechanisms#Tuple_types|"Tuple types"]] . You will always use tuples for the argument to call and item, because these features must be applicable to any routine, and so cannot rely on a fixed number of arguments. Instead they take a single tuple intended to contain all the arguments. This property is reflected in the type of the second actual generic parameter to f, corresponding to ARGS (the formal generic parameter of FUNCTION): here it's TUPLE [REAL] to require an argument such as [x], where x is of type REAL. +we don't directly pass x to item; instead, we pass a one-element tuple [x], using the syntax for manifest tuples introduced in [[ET: Other Mechanisms#Tuple_types|"Tuple types"]] . You will always use tuples for the argument to call and item, because these features must be applicable to any routine, and so cannot rely on a fixed number of arguments. Instead they take a single tuple intended to contain all the arguments. This property is reflected in the type of the second actual generic parameter to f, corresponding to ARGS (the formal generic parameter of FUNCTION): here it's TUPLE [REAL] to require an argument such as [x], where x is of type REAL. Similarly, consider the agent that the call seen above: diff --git a/documentation/current/method/eiffel-tutorial-et/et-design-contract-tm-assertions-and-exceptions.wiki b/documentation/current/method/eiffel-tutorial-et/et-design-contract-tm-assertions-and-exceptions.wiki index 92b39663..4bb3fd38 100644 --- a/documentation/current/method/eiffel-tutorial-et/et-design-contract-tm-assertions-and-exceptions.wiki +++ b/documentation/current/method/eiffel-tutorial-et/et-design-contract-tm-assertions-and-exceptions.wiki @@ -1,5 +1,4 @@ -[[Property:title|8 Design by Contract (tm), Assertions and Exceptions]] -[[Property:link_title|ET: Design by Contract (tm), Assertions and Exceptions]] +[[Property:title|ET: Design by Contract (tm), Assertions and Exceptions]] [[Property:weight|-8]] [[Property:uuid|2ef367c9-34d9-d45e-a722-163b39581405]] Eiffel directly implements the ideas of Design by Contract™ , which enhance software reliability and provide a sound basis for software specification, documentation and testing, as well as exception handling and the proper use of inheritance. @@ -39,7 +38,7 @@ In addition to preconditions and postconditions, contract clauses include '''cla ==Expressing assertions== -Eiffel provides syntax for expressing preconditions (require), postconditions (ensure) and class invariants (invariant), as well as other assertion constructs studied later (see [[10 Other Mechanisms#Instructions|"Instructions"]] ): loop invariants and variants, check instructions. +Eiffel provides syntax for expressing preconditions (require), postconditions (ensure) and class invariants (invariant), as well as other assertion constructs studied later (see [[ET: Other Mechanisms#Instructions|"Instructions"]] ): loop invariants and variants, check instructions. Here is a partial update of class ACCOUNT with more assertions: @@ -131,7 +130,7 @@ Note in this respect that guaranteeing a precondition does not necessarily mean, possibly with an else part. But if the context of the call, in the client's code, implies that n is positive -- perhaps because some preceding call set it to the sum of two squares -- then there is no need for an if or similar construct. -{{note|In such a case, a check instruction as introduced later ( [[10 Other Mechanisms#Instructions|"Instructions"]] ) is recommended if the reason for omitting the test is non-trivial. }} +{{note|In such a case, a check instruction as introduced later ( [[ET: Other Mechanisms#Instructions|"Instructions"]] ) is recommended if the reason for omitting the test is non-trivial. }} ==Using contracts for built-in reliability== @@ -161,11 +160,11 @@ But of course for an incorrect system the best way to find out where the bug is * all : same as invariant, plus check instructions, loop invariants and loop variants. -An assertion violation, if detected at run time under one of these options other than the first, will cause an exception ( [[8 Design by Contract (tm), Assertions and Exceptions#exception_handling|"Exception handling"]] ). Unless the software has an explicit "retry" plan as explained in the discussion of exceptions, the violation will produce an exception trace and cause termination (or, in EiffelStudio, a return to the environment's browsing and debugging facilities at the point of failure). If present, the label of the violated sub clause will be displayed, to help identify the problem. +An assertion violation, if detected at run time under one of these options other than the first, will cause an exception ( [[ET: Design by Contract (tm), Assertions and Exceptions#exception_handling|"Exception handling"]] ). Unless the software has an explicit "retry" plan as explained in the discussion of exceptions, the violation will produce an exception trace and cause termination (or, in EiffelStudio, a return to the environment's browsing and debugging facilities at the point of failure). If present, the label of the violated sub clause will be displayed, to help identify the problem. The default is require. This is particularly interesting in connection with the Eiffel method's insistence on reuse: with libraries such as EiffelBase, richly equipped with preconditions expressing terms of use, an error in the '''client software''' will often lead, for example through an incorrect argument, to violating one of these preconditions. A somewhat paradoxical consequence is that even an application developer who does not apply the method too well (out of carelessness, haste, indifference or ignorance) will still benefit from the presence of contracts in someone else's library code. -During development and testing, assertion monitoring should be turned on at the highest possible level. Combined with static typing and the immediate feedback of compilation techniques such as the Melting Ice Technology, this permits the development process mentioned in the section [[3 The Software Process in Eiffel#Quality_and_functionality|"Quality and functionality"]] , where errors are exterminated at birth. No one who has not practiced the method in a real project can imagine how many mistakes are found in this way; surprisingly often, a violation will turn out to affect an assertion that was just included for goodness' sake, the developer being convinced that it could never "possibly" fail to be satisfied. +During development and testing, assertion monitoring should be turned on at the highest possible level. Combined with static typing and the immediate feedback of compilation techniques such as the Melting Ice Technology, this permits the development process mentioned in the section [[ET: The Software Process in Eiffel#Quality_and_functionality|"Quality and functionality"]], where errors are exterminated at birth. No one who has not practiced the method in a real project can imagine how many mistakes are found in this way; surprisingly often, a violation will turn out to affect an assertion that was just included for goodness' sake, the developer being convinced that it could never "possibly" fail to be satisfied. By providing a precise reference (the description of what the software is supposed to do) against which to assess the reality (what the software actually does), Design by Contract™ profoundly transforms the activities of debugging, testing and quality assurance. @@ -209,25 +208,25 @@ The words class interface are used instead of just class * Names and signatures (argument and result type information) for exported features. -* Header comments of these features, which carry informal descriptions of their purpose. (Hence the importance, mentioned in section [[4 Hello World|"Hello World"]], of always including such comments and writing them carefully.) +* Header comments of these features, which carry informal descriptions of their purpose. (Hence the importance, mentioned in "[[ET: Hello World|Hello World]]", of always including such comments and writing them carefully.) * Preconditions and postconditions of these features (at least the subclauses involving only exported features). * Class invariant (same observation). -The following elements, however, are not in the Contract Form: any information about non-exported features; all the routine bodies (do clauses, or the external and once variants seen in [[5 The Static Picture: System Organization#External_software|"External software"]] above and [[10 Other Mechanisms#Once_routines_and_shared_objects|"Once routines and shared objects"]] below); assertion subclauses involving non-exported features; and some keywords not useful in the documentation. +The following elements, however, are not in the Contract Form: any information about non-exported features; all the routine bodies (do clauses, or the external and once variants seen in [[ET: The Static Picture: System Organization#External_software|"External software"]] above and [[ET: Other Mechanisms#Once_routines_and_shared_objects|"Once routines and shared objects"]] below); assertion subclauses involving non-exported features; and some keywords not useful in the documentation. -In accordance with the Uniform Access principle (described in [[6 The Dynamic Structure: Execution Model|"Objects, fields, values, and references"]] ), the Contract Form does not distinguish between attributes and argument-less queries. In the above example, balance could be one or the other, as it makes no difference to clients, except possibly for performance. +In accordance with the Uniform Access principle (described in [[ET: The Dynamic Structure: Execution Model|"Objects, fields, values, and references"]] ), the Contract Form does not distinguish between attributes and argument-less queries. In the above example, balance could be one or the other, as it makes no difference to clients, except possibly for performance. The Contract Form is the fundamental tool for using supplier classes in the Eiffel method. It enables client authors to reuse software elements without having to read their source code. This is a crucial requirement in large-scale industrial developments. The Contract Form satisfies two key requirements of good software documentation:
* It is truly abstract, free from the implementation details of what it describes and concentrating instead on its functionality. -* Rather than being developed separately -- an unrealistic requirement, hard to impose on developers initially and becoming impossible in practice if we expect the documentation to remain up to date as the software evolves -- the documentation is extracted from the software itself. It is not a separate product but a different view of the same product. This prolongs the '''Single Product''' principle that lies at the basis of Eiffel's seamless development model (shown in [[3 The Software Process in Eiffel|"The Software Process in Eiffel"]] ). +* Rather than being developed separately -- an unrealistic requirement, hard to impose on developers initially and becoming impossible in practice if we expect the documentation to remain up to date as the software evolves -- the documentation is extracted from the software itself. It is not a separate product but a different view of the same product. This prolongs the '''Single Product''' principle that lies at the basis of Eiffel's seamless development model (shown in [[ET: The Software Process in Eiffel|The Software Process in Eiffel]] ). The Contract Form is only one of the relevant views. EiffelStudio, for example, generates graphical representations of system structures, to show classes and their relations -- client, inheritance -- according to the conventions of BON (the Business Object Notation). In accordance with the principles of seamlessness and reversibility, EiffelStudio lets you both work on the text, producing the graphics on the fly, or work on the graphics, updating the text on the fly; you can alternate as you wish between these two modes. The resulting process is quite different from more traditional approaches based on separate tools: an analysis and CASE workbench, often based on UML, to deal with an initial "bubble-and-arrow" description; and a separate programming environment, to deal with implementation aspects only. In Eiffel the environment provides consistent, seamless support from beginning to end. -The Contract Form -- or its variant the Flat-Contract Form, which takes account of inheritance ( [[9 Inheritance#Flat_and_Flat-Contract_Forms|"Flat and Flat-Contract Forms"]] ) are the standard form of library documentation, used extensively, for example, in the book [http://www.eiffel.com/doc/page.html Reusable Software] (see bibliography). Assertions play a central role in such documentation by expressing the terms of the contract. As demonstrated a contrario by the widely publicized $500-million crash of the Ariane-5 rocket launcher in June of 1996, due to the incorrect reuse of a software module from the Ariane-4 project, '''reuse without a contract documentation''' is the path to disaster. Non-reuse would, in fact, be preferable. +The Contract Form -- or its variant the Flat-Contract Form, which takes account of inheritance ( [[ET: Inheritance#Flat_and_Flat-Contract_Forms|"Flat and Flat-Contract Forms"]] ) are the standard form of library documentation, used extensively, for example, in the book [http://www.eiffel.com/doc/page.html Reusable Software] (see bibliography). Assertions play a central role in such documentation by expressing the terms of the contract. As demonstrated a contrario by the widely publicized $500-million crash of the Ariane-5 rocket launcher in June of 1996, due to the incorrect reuse of a software module from the Ariane-4 project, '''reuse without a contract documentation''' is the path to disaster. Non-reuse would, in fact, be preferable. ==Exception handling== @@ -319,13 +318,13 @@ Concretely, exceptions may result from the following events:
* 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.) -It is sometimes useful, when handling exceptions in rescue clauses, to ascertain the exact nature of the exception that got the execution there. For this it is suffices to inherit from the Kernel Library class EXCEPTIONS, which provides queries such as exception, giving the code for the last exception, and symbolic names ( [[10 Other Mechanisms#Constant_attributes|"Constant attributes"]] ) for all such codes, such as No_more_memory. You can then process different exceptions differently by testing exception against various possibilities. The method strongly suggests, however, that exception handling code should remain simple; a complicated algorithm in a rescue clause is usually a sign that the mechanism is being misused. Class EXCEPTIONS also provides various facilities for fine-tuning the exception facilities, such as a procedure raise 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. +It is sometimes useful, when handling exceptions in rescue clauses, to ascertain the exact nature of the exception that got the execution there. For this it is suffices to inherit from the Kernel Library class EXCEPTIONS, which provides queries such as exception, giving the code for the last exception, and symbolic names ( [[ET: Other Mechanisms#Constant_attributes|"Constant attributes"]] ) for all such codes, such as No_more_memory. You can then process different exceptions differently by testing exception against various possibilities. The method strongly suggests, however, that exception handling code should remain simple; a complicated algorithm in a rescue clause is usually a sign that the mechanism is being misused. Class EXCEPTIONS also provides various facilities for fine-tuning the exception facilities, such as a procedure raise 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. ==Other applications of Design by Contract™== The Design by Contract™ ideas pervade the Eiffel method. In addition to the applications just mentioned, they have two particularly important consequences:
-* They make it possible to use Eiffel for analysis and design. At a high level of abstraction, it is necessary to be precise too. With the exception of BON, object-oriented analysis and design methods tend to favor abstraction over precision. Thanks to assertions, it is possible to express precise properties of a system ("At what speed should the alarm start sounding?") without making any commitment to implementation. The discussion of deferred classes ( [[9 Inheritance#Applications_of_deferred_classes|"Applications of deferred classes"]] ) will show how to write a purely descriptive, non-software model in Eiffel, using contracts to describe the essential properties of a system without any computer or software aspect. -* Assertions also serve to control the power of inheritance-related mechanisms -- redeclaration, polymorphism, dynamic binding -- and channel them to correct uses by assigning the proper semantic limits. See [[9 Inheritance#Inheritance_and_contracts|"Inheritance and contracts"]] . +* They make it possible to use Eiffel for analysis and design. At a high level of abstraction, it is necessary to be precise too. With the exception of BON, object-oriented analysis and design methods tend to favor abstraction over precision. Thanks to assertions, it is possible to express precise properties of a system ("At what speed should the alarm start sounding?") without making any commitment to implementation. The discussion of deferred classes ( [[ET: Inheritance#Applications_of_deferred_classes|"Applications of deferred classes"]] ) will show how to write a purely descriptive, non-software model in Eiffel, using contracts to describe the essential properties of a system without any computer or software aspect. +* Assertions also serve to control the power of inheritance-related mechanisms -- redeclaration, polymorphism, dynamic binding -- and channel them to correct uses by assigning the proper semantic limits. See [[ET: Inheritance#Inheritance_and_contracts|"Inheritance and contracts"]] . 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 5933150a..7329f7eb 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 @@ -1,5 +1,4 @@ -[[Property:title|6 The Dynamic Structure: Execution Model]] -[[Property:link_title|ET: The Dynamic Structure: Execution Model]] +[[Property:title|ET: The Dynamic Structure: Execution Model]] [[Property:weight|-10]] [[Property:uuid|1f3f2707-9129-4dca-76c7-157143d7ae74]] A system with a certain static structure describes a set of possible executions. The run-time model governs the structure of the data (objects) created during such executions. @@ -203,7 +202,7 @@ known as a creation call. Such a creation call will have the same effect as the 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"]] . }} +{{info|Some variants of the basic creation instruction will be reviewed later: instruction with an explicit type; creation expressions. See [[ET: Other Mechanisms#Creation_variants|"Creation variants"]] . }} ==Entities== @@ -458,7 +457,7 @@ A more general variant of is_equal is used under the form: equal (x, y) -This is always defined, even if x is void, returning true whenever is_equal would but also if x and y are both void. (In contrast, x.is_equal (y) is not defined for void x and would, if evaluated, yield an exception as explained in [[8 Design by Contract (tm), Assertions and Exceptions#Exception_handling|"Exception handling"]] below.) +This is always defined, even if x is void, returning true whenever is_equal would but also if x and y are both void. (In contrast, x.is_equal (y) is not defined for void x and would, if evaluated, yield an exception as explained in [[ET: Design by Contract (tm), Assertions and Exceptions#Exception_handling|"Exception handling"]] below.) Void denotes a void reference. So you can make x void through the assignment @@ -533,7 +532,7 @@ feature {NONE} -- Implementation -- List of deposits since account's opening. -This form indicates that the features appearing in that clause are only '''available''' -- in the sense of available for calls, as used in the Feature Call rule -- to the classes listed. In the example feature all_deposits is only available to NONE . Because of the [[5 The Static Picture: System Organization#The_global_inheritance_structure|global inheritance structure]], this means it is in fact available to no useful client at all, and is equivalent in practice to feature { } with an empty class list, although the form listing NONE explicitly is more visible and hence preferred. +This form indicates that the features appearing in that clause are only '''available''' -- in the sense of available for calls, as used in the Feature Call rule -- to the classes listed. In the example feature all_deposits is only available to NONE . Because of the [[ET: The Static Picture: System Organization#The_global_inheritance_structure|global inheritance structure]], this means it is in fact available to no useful client at all, and is equivalent in practice to feature { } with an empty class list, although the form listing NONE explicitly is more visible and hence preferred. @@ -549,7 +548,7 @@ Besides fully exported features (introduced by feature ... ; withou feature {A, B, ...} -for arbitrary classes A, B, ... This enables a group of related classes to provide each other with privileged access, without requiring the introduction of a special module category above the class level (see [[5 The Static Picture: System Organization#Clusters|"Clusters"]] ). +for arbitrary classes A, B, ... This enables a group of related classes to provide each other with privileged access, without requiring the introduction of a special module category above the class level (see [[ET: The Static Picture: System Organization#Clusters|"Clusters"]] ). Exporting features selectively to a set of classes A, B, ... also makes them available to the descendants of these classes. So a feature clause beginning with just feature is equivalent to one starting with feature {ANY} . @@ -621,11 +620,11 @@ The levels of privilege available to the class author include, for any field: * Export it for free read and write by any client, by also exporting a procedure of the set_attribute kind. * Export it in '''restricted-write''' mode, by exporting a procedure such as deposit of class ACCOUNT, which adds a specified amount to the balance field, rather than directly setting the balance. -The last case is particularly interesting is that it allows the class designer to set the precise way in which clients will manipulate the class instances, respecting the properties of the class and its integrity. The exported routines may, through the Design by Contract mechanism reviewed later in ( [[8 Design by Contract (tm), Assertions and Exceptions]] ), place some further restrictions on the permitted modifications, for example by requiring the withdrawn amount to be positive. +The last case is particularly interesting is that it allows the class designer to set the precise way in which clients will manipulate the class instances, respecting the properties of the class and its integrity. The exported routines may, through the Design by Contract mechanism reviewed later in ( [[ET: Design by Contract (tm), Assertions and Exceptions]] ), place some further restrictions on the permitted modifications, for example by requiring the withdrawn amount to be positive. These rules follow directly from the more general goals (reusability, extendibility, reliability) and principles (Uniform Access, information hiding) underlying Eiffel software design. They reflect a view that each class must denote a well-understood abstraction, defined by a set of exported features chosen by the class designer -- the "control panel". -The class documentation (see [[8 Design by Contract (tm), Assertions and Exceptions#The_contract_form_of_a_class|the contract form of a class]] ) makes this view clear to client authors; no violation of that interface is permitted. This approach also paves the way for future '''generalization''' -- the final step of the cluster lifecycle, seen earlier in the section [[3 The Software Process in Eiffel#Generalization_and_reuse|Generalization and reuse]] -- of the most promising components, and their inclusion into reusable libraries. +The class documentation (see [[ET: Design by Contract (tm), Assertions and Exceptions#The_contract_form_of_a_class|the contract form of a class]] ) makes this view clear to client authors; no violation of that interface is permitted. This approach also paves the way for future '''generalization''' -- the final step of the cluster lifecycle, seen earlier in the section [[ET: The Software Process in Eiffel#Generalization_and_reuse|Generalization and reuse]] -- of the most promising components, and their inclusion into reusable libraries. diff --git a/documentation/current/method/eiffel-tutorial-et/et-eiffel-tutorial-copyright.wiki b/documentation/current/method/eiffel-tutorial-et/et-eiffel-tutorial-copyright.wiki index aae2d526..450045b8 100644 --- a/documentation/current/method/eiffel-tutorial-et/et-eiffel-tutorial-copyright.wiki +++ b/documentation/current/method/eiffel-tutorial-et/et-eiffel-tutorial-copyright.wiki @@ -1,5 +1,4 @@ -[[Property:title|Eiffel Tutorial Copyright]] -[[Property:link_title|ET: Eiffel Tutorial Copyright]] +[[Property:title|ET: Eiffel Tutorial Copyright]] [[Property:weight|0]] [[Property:uuid|105e9956-f168-b060-a6be-e78b221f269a]] ====MANUAL IDENTIFICATION AND COPYRIGHT==== diff --git a/documentation/current/method/eiffel-tutorial-et/et-general-properties.wiki b/documentation/current/method/eiffel-tutorial-et/et-general-properties.wiki index f5893685..44b79b1e 100644 --- a/documentation/current/method/eiffel-tutorial-et/et-general-properties.wiki +++ b/documentation/current/method/eiffel-tutorial-et/et-general-properties.wiki @@ -1,5 +1,4 @@ -[[Property:title|2 General Properties]] -[[Property:link_title|ET: General Properties]] +[[Property:title|ET: General Properties]] [[Property:weight|-14]] [[Property:uuid|1ad0b1d5-7ac6-9f55-92ec-ba6f42aee690]] Here is an overview of the facilities supported by Eiffel:
diff --git a/documentation/current/method/eiffel-tutorial-et/et-genericity-and-arrays.wiki b/documentation/current/method/eiffel-tutorial-et/et-genericity-and-arrays.wiki index a53492bc..9350f805 100644 --- a/documentation/current/method/eiffel-tutorial-et/et-genericity-and-arrays.wiki +++ b/documentation/current/method/eiffel-tutorial-et/et-genericity-and-arrays.wiki @@ -1,5 +1,4 @@ -[[Property:title|7 Genericity and Arrays]] -[[Property:link_title|ET: Genericity and Arrays]] +[[Property:title|ET: Genericity and Arrays]] [[Property:weight|-9]] [[Property:uuid|7f3bd1d7-357e-031d-9faa-b00594aa9ae0]] Some of the classes that we will need, particularly in libraries, are '''container''' classes, describing data structures made of a number of objects of the same or similar types. Examples of containers include arrays, stacks and lists. The class DEPOSIT_LIST posited in earlier examples describes containers. diff --git a/documentation/current/method/eiffel-tutorial-et/et-hello-world.wiki b/documentation/current/method/eiffel-tutorial-et/et-hello-world.wiki index 61bdbef8..4c0af4f5 100644 --- a/documentation/current/method/eiffel-tutorial-et/et-hello-world.wiki +++ b/documentation/current/method/eiffel-tutorial-et/et-hello-world.wiki @@ -1,5 +1,4 @@ -[[Property:title|4 Hello World]] -[[Property:link_title|ET: Hello World]] +[[Property:title|ET: Hello World]] [[Property:weight|-12]] [[Property:uuid|5b286f94-dd63-1169-a64e-74b5f8c5ef14]] When discovering any approach to software construction, however ambitious its goals, it is reassuring to see first a small example of the big picture -- a complete program to print the famous "Hello World" string. Here is how to perform this fascinating task in the Eiffel notation. @@ -56,7 +55,7 @@ The name of the class is HELLO. Any class may contain "features"; < The definition of make appears in a feature clause. There may be any number of such clauses (to separate features into logical categories), and each may contain any number of feature declarations. Here we have only one. -The line starting with -- (two hyphen signs) is a comment; more precisely it is a "header comment", which style rules invite software developers to write for every such feature, just after the point at which the feature is named. As will be seen in [[8 Design by Contract (tm), Assertions and Exceptions#The_contract_form_of_a_class|"The contract form of a class"]], the tools of EiffelStudio know about this convention and use it to include the header comment in the automatically generated class documentation. +The line starting with -- (two hyphen signs) is a comment; more precisely it is a "header comment", which style rules invite software developers to write for every such feature, just after the point at which the feature is named. As will be seen in [[ET: Design by Contract (tm), Assertions and Exceptions#The_contract_form_of_a_class|"The contract form of a class"]], the tools of EiffelStudio know about this convention and use it to include the header comment in the automatically generated class documentation. The body of the feature is introduced by the do keyword and terminated by end. It consists of two output instructions. They both use io, a generally available reference to an object that provides access to standard input and output mechanisms; the notation io.f, for some feature f of the corresponding library class (STD_FILES, in this case), means "apply f to io". Here we use two such features: * put_string outputs a string, passed as argument, here "Hello World". diff --git a/documentation/current/method/eiffel-tutorial-et/et-inheritance.wiki b/documentation/current/method/eiffel-tutorial-et/et-inheritance.wiki index 703773c3..49521bee 100644 --- a/documentation/current/method/eiffel-tutorial-et/et-inheritance.wiki +++ b/documentation/current/method/eiffel-tutorial-et/et-inheritance.wiki @@ -1,5 +1,4 @@ -[[Property:title|9 Inheritance]] -[[Property:link_title|ET: Inheritance]] +[[Property:title|ET: Inheritance]] [[Property:weight|-7]] [[Property:uuid|c90e6ee3-b39d-48e5-2321-a34e12fd5327]] Inheritance is a powerful and attractive technique. A look at either the practice or literature shows, however, that it is not always well applied. Eiffel has made a particular effort to tame inheritance for the benefit of modelers and software developers. Many of the techniques are original with Eiffel. Paul Dubois has written (comp.lang.python Usenet newsgroup, 23 March 1997): there are two things that [Eiffel] got right that nobody else got right anywhere else: support for design by contract, and multiple inheritance. Everyone should understand these "correct answers" if only to understand how to work around the limitations in other languages. @@ -22,9 +21,9 @@ feature ... -This makes D an heir of A, B and any other class listed. Eiffel supports '''multiple''' inheritance: a class may have as many parents as it needs. Later sections ( [[9 Inheritance#Multiple_inheritance_and_renaming|"Multiple inheritance and renaming"]] and [[9 Inheritance#Repeated_inheritance_and_selection|"Repeated inheritance and selection"]] ) will explain how to handle possible conflicts between parent features. +This makes D an heir of A, B and any other class listed. Eiffel supports '''multiple''' inheritance: a class may have as many parents as it needs. Later sections ( [[ET: Inheritance#Multiple_inheritance_and_renaming|"Multiple inheritance and renaming"]] and [[ET: Inheritance#Repeated_inheritance_and_selection|"Repeated inheritance and selection"]] ) will explain how to handle possible conflicts between parent features. -{{note|This discussion will rely on the terminology introduced in [[5 The Static Picture: System Organization|The Static Picture: System Organization]]: descendants of a class are the class itself, its heirs, the heirs of its heirs and so on. Proper descendants exclude the class itself. The reverse notions are ancestors and proper ancestors. }} +{{note|This discussion will rely on the terminology introduced in [[ET: The Static Picture: System Organization|The Static Picture: System Organization]]: descendants of a class are the class itself, its heirs, the heirs of its heirs and so on. Proper descendants exclude the class itself. The reverse notions are ancestors and proper ancestors. }} By default D will simply include all the original features of A, B, ..., to which it may add its own through its feature clauses if any. But the inheritance mechanism is more flexible, allowing D to adapt the inherited features in many ways. Each parent name -- A, B, ... in the example -- can be followed by a Feature Adaptation clause, with subclauses, all optional, introduced by keywords rename, export, undefine, redefine and select, enabling the author of D to make the best use of the inheritance mechanism by tuning the inherited features to the precise needs of D. This makes inheritance a principal tool in the Eiffel process, mentioned earlier, of carefully crafting each individual class, like a machine, for the benefit of its clients. The next sections review the various Feature Adaptation subclauses. @@ -80,7 +79,7 @@ In a redefinition, the original version -- such as the ACCOUNT impl ... Instructions to update the interest ... -Besides changing the implementation of a routine, a redefinition can turn an argument-less function into an attribute; for example a proper descendant of ACCOUNT could redefine deposits_count, originally a function, as an attribute. The Uniform Access Principle (introduced in [[6 The Dynamic Structure: Execution Model|The Dynamic Structure: Execution Model]] ) guarantees that the redefinition makes no change for clients, which will continue to use the feature under the form +Besides changing the implementation of a routine, a redefinition can turn an argument-less function into an attribute; for example a proper descendant of ACCOUNT could redefine deposits_count, originally a function, as an attribute. The Uniform Access Principle (introduced in [[ET: The Dynamic Structure: Execution Model|The Dynamic Structure: Execution Model]] ) guarantees that the redefinition makes no change for clients, which will continue to use the feature under the form acc.deposits_count @@ -91,7 +90,7 @@ The inheritance mechanism is relevant to both roles of classes: module and type. '''Polymorphic assignment''' supports this second role. In an assignment x := y, the types of x and y do not have, with inheritance, to be identical; the rule is that the type of y must simply '''conform''' to the type of x. A class D conforms to a class A if and only if it is a descendant of A (which includes the case in which A and D are the same class); if these classes are generic, conformance of D [ U ] to C [ T ] requires in addition that type U conform to type T (through the recursive application of the same rules). -{{note|In addition, it will be shown in the discussion of tuples ([[10 Other Mechanisms#Tuple_types|"Tuple types"]]), that TUPLE [X] conforms to TUPLE, TUPLE [X, Y] to TUPLE [X] and so on. }} +{{note|In addition, it will be shown in the discussion of tuples ([[ET: Other Mechanisms#Tuple_types|"Tuple types"]]), that TUPLE [X] conforms to TUPLE, TUPLE [X, Y] to TUPLE [X] and so on. }} So with the inheritance structure that we have seen, the declarations @@ -113,7 +112,7 @@ For polymorphism to respect the reliability requirements of Eiffel, it must be c The second case listed in the rule is a call such as target.routine(..., y, ...) where the routine declaration is of the form routine (..., x: SOME_TYPE). The relationship between y, the actual argument in the call, and the corresponding formal argument x, is exactly the same as in an assignment x := y: not just the type rule, as expressed by Type Conformance (the type of y must conform to SOME_TYPE), but also the actual run-time effect which, as for assignments, will be either a reference attachment or, for expanded types, a copy. -The ability to accept the assignment x := Void for x of any reference type (see [[6 The Dynamic Structure: Execution Model#Basic_operations|"Basic operations"]] ) is a consequence of the Type Conformance rule, since Void is of type NONE which by construction ([[5 The Static Picture: System Organization#The_global_inheritance_structure|"The global inheritance structure"]] ) conforms to all types. +The ability to accept the assignment x := Void for x of any reference type (see [[ET: The Dynamic Structure: Execution Model#Basic_operations|"Basic operations"]] ) is a consequence of the Type Conformance rule, since Void is of type NONE which by construction ([[ET: The Static Picture: System Organization#The_global_inheritance_structure|"The global inheritance structure"]] ) conforms to all types. Polymorphism also yields a more precise definition of "instance". A '''direct instance''' of a type A is an object created from the exact pattern defined by the declaration of A 's base class, with one field for each of the class attributes; you will obtain it through a creation instruction of the form create x ..., for x of type A, or by cloning an existing direct instance. An '''instance''' of A is a direct instance of any type conforming to A: A itself, but also any type based on descendant classes. So an instance of SAVINGS_ACCOUNT is also an instance, although not a direct instance, of ACCOUNT. @@ -272,7 +271,7 @@ Deferred classes cover abstract notions with many possible variants. They are wi These applications make deferred classes a central tool of the Eiffel method's support for seamlessness and reversibility. The last one in particular uses deferred classes and features to model objects from an application domain, without any commitment to implementation, design, or even software (and computers). Deferred classes are the ideal tool here: they express the properties of the domain's abstractions, without any temptation of implementation bias, yet with the precision afforded by type declarations, inheritance structures (to record classifications of the domain concepts), and contracts to express the abstract properties of the objects being described. -Rather than using a separate method and notation for analysis and design, this approach integrates seamlessly with the subsequent phases (assuming the decision is indeed taken to develop a software system): it suffices to refine the deferred classes progressively by introducing effective elements, either by modifying the classes themselves, or by introducing design- and implementation-oriented descendants. In the resulting system, the classes that played an important role for analysis, and are the most meaningful for customers, will remain important; as we have seen ( [[3 The Software Process in Eiffel#Seamlessness_and_reversibility|"Seamlessness and reversibility"]] ) this direct mapping property is a great help for extendibility. +Rather than using a separate method and notation for analysis and design, this approach integrates seamlessly with the subsequent phases (assuming the decision is indeed taken to develop a software system): it suffices to refine the deferred classes progressively by introducing effective elements, either by modifying the classes themselves, or by introducing design- and implementation-oriented descendants. In the resulting system, the classes that played an important role for analysis, and are the most meaningful for customers, will remain important; as we have seen ( [[ET: The Software Process in Eiffel#Seamlessness_and_reversibility|"Seamlessness and reversibility"]] ) this direct mapping property is a great help for extendibility. The following sketch (from the book [http://eiffel.com/doc/oosc/ Object-Oriented Software Construction] ) illustrates these ideas on the example of scheduling the programs of a TV station. This is pure modeling of an application domain; no computers or software are involved yet. The class describes the notion of program segment. @@ -345,7 +344,7 @@ Some deferred classes describe a structural property, useful to the description For such classes it is again essential to permit effective features in a deferred class, and to include assertions. For example class COMPARABLE declares infix "<" as deferred, and expresses >, >= and <= effectively in terms of it. -{{note|The type like Current will be explained in [[9 Inheritance#Covariance_and_anchored_declarations|"Covariance and anchored declarations"]] ; you may understand it, in the following class, as equivalent to COMPARABLE. }} +{{note|The type like Current will be explained in [[ET: Inheritance#Covariance_and_anchored_declarations|"Covariance and anchored declarations"]] ; you may understand it, in the following class, as equivalent to COMPARABLE. }} note description: "Objects that can be compared according to a total preorder relation" @@ -478,9 +477,9 @@ For a precondition, using require else with a new assertion will pe The last case -- retaining the original -- is frequent but by no means universal. -The Assertion Redeclaration rule applies to '''redeclarations'''. This terms covers not just redefinition but also effecting (the implementation, by a class, of a feature that it inherits deferred). The rules -- not just for assertions but also, as reviewed below, for typing -- are indeed the same in both cases. Without the Assertion Redeclaration rule, assertions on deferred features, such as those on extend, count and forth in [[9 Inheritance#Deferred_features_and_classes|"Deferred features and classes"]] , would be almost useless -- wishful thinking; the rule makes them binding on all effectings in descendants. +The Assertion Redeclaration rule applies to '''redeclarations'''. This terms covers not just redefinition but also effecting (the implementation, by a class, of a feature that it inherits deferred). The rules -- not just for assertions but also, as reviewed below, for typing -- are indeed the same in both cases. Without the Assertion Redeclaration rule, assertions on deferred features, such as those on extend, count and forth in [[ET: Inheritance#Deferred_features_and_classes|"Deferred features and classes"]] , would be almost useless -- wishful thinking; the rule makes them binding on all effectings in descendants. -From the Assertion Redeclaration rule follows an interesting technique: '''abstract preconditions'''. What needs to be weakened for a precondition (or strengthened for a postcondition) is not the assertion's concrete semantics but its abstract specification as seen by the client. A descendant can change the implementation of that specification as it pleases, even to the effect of strengthening the concrete precondition, as long as the abstract form is kept or weakened. The precondition of procedure extend in the deferred class LIST provided an example. We wrote the routine (in [[9 Inheritance#Deferred_features_and_classes|"Deferred features and classes"]] ) as +From the Assertion Redeclaration rule follows an interesting technique: '''abstract preconditions'''. What needs to be weakened for a precondition (or strengthened for a postcondition) is not the assertion's concrete semantics but its abstract specification as seen by the client. A descendant can change the implementation of that specification as it pleases, even to the effect of strengthening the concrete precondition, as long as the abstract form is kept or weakened. The precondition of procedure extend in the deferred class LIST provided an example. We wrote the routine (in [[ET: Inheritance#Deferred_features_and_classes|"Deferred features and classes"]] ) as extend (x: G) -- Add `x' at end of list. @@ -524,7 +523,7 @@ It is not an error to inherit two deferred features from different parents under More generally, it is permitted to have any number of deferred features and at most one effective feature that share the same name: the effective version, if present will effect all the others. -All this is not a violation of the Final Name rule (defined in [[9 Inheritance#Multiple_inheritance_and_renaming|"Multiple inheritance and renaming"]] ), since the name clashes prohibited by the rule involve two different features having the same final name; here the result is just one feature, resulting from the join of all the inherited versions. +All this is not a violation of the Final Name rule (defined in [[ET: Inheritance#Multiple_inheritance_and_renaming|"Multiple inheritance and renaming"]] ), since the name clashes prohibited by the rule involve two different features having the same final name; here the result is just one feature, resulting from the join of all the inherited versions. Sometimes we may want to join ''effective'' features inherited from different parents, assuming again the features have compatible signatures. One way is to redefine them all into a new version. That is, list each in a redefine clause, then write a redefined version of the feature. In this case, they again become one feature, with no name clash in the sense of the Final Name rule. But in other cases we may simply want one of the inherited implementations to take over the others. The solution is to revert to the preceding case by '''uneffecting''' the other features; uneffecting an inherited effective feature makes it deferred (this is the reverse of effecting, which turns an inherited deferred feature into an effective one). The syntax uses the undefine subclause: @@ -602,7 +601,7 @@ This is part of the power of the object-oriented form of reuse, but can create a These observations suggest ways to produce, from a class text, a version that is equivalent feature-wise and assertion-wise, but has no inheritance dependency. This is called the '''Flat Form''' of the class. It is a class text that has no inheritance clause and includes all the features of the class, immediate (declared in the class itself) as well as inherited. For the inherited features, the flat form must of course take account of all the feature adaptation mechanisms: renaming (each feature must appear under its final name), redefinition, effecting, uneffecting and export status change. For redeclared features, require else clauses are or-ed with the precursors' preconditions, and ensure then clauses are and-ed with precursors' postconditions. For invariants, all the ancestors' clauses are concatenated. As a result, the flat form yields a view of the class, its features and its assertions that conforms exactly to the view offered to clients and (except for polymorphic uses) heirs. -As with the Contract Form ( [[8 Design by Contract (tm), Assertions and Exceptions#The_contract_form_of_a_class|"The contract form of a class"]] ), producing the Flat Form is the responsibility of tools in the development environment. In EiffelStudio, you will just click the "Flat" icon. +As with the Contract Form ( [[ET: Design by Contract (tm), Assertions and Exceptions#The_contract_form_of_a_class|"The contract form of a class"]] ), producing the Flat Form is the responsibility of tools in the development environment. In EiffelStudio, you will just click the "Flat" icon. The Contract Form of the Flat Form of a class is known as its '''Flat-Contract Form'''. It gives the complete interface specification, documenting all exported features and assertions -- immediate or inherited -- and hiding implementation aspects. It is the appropriate documentation for a class. @@ -669,7 +668,7 @@ So if you traverse a list computer_users: LIST [UNIVERSITY_PERSON] You may, if desired, redefine faculty_account in class TEACHING_ASSISTANT, using student_account if necessary, to take into consideration the existence of another account. But in all cases we need a precise disambiguation of what computer_account means for a TEACHING_ASSISTANT object known only through a UNIVERSITY_PERSON entity. -The select is only needed in case of replication. If the Repeated Inheritance rule would imply sharing, as with change_address, and one or both of the shared versions has been redeclared, the Final Name rule makes the class invalid, since it now has '''two different features''' with the same name. (This is only a problem if both versions are effective; if one or both are deferred there is no conflict but a mere case of feature joining as explained in [[9 Inheritance#Join_and_uneffecting|"Join and uneffecting"]] .) The two possible solutions follow from the previous discussions: +The select is only needed in case of replication. If the Repeated Inheritance rule would imply sharing, as with change_address, and one or both of the shared versions has been redeclared, the Final Name rule makes the class invalid, since it now has '''two different features''' with the same name. (This is only a problem if both versions are effective; if one or both are deferred there is no conflict but a mere case of feature joining as explained in [[ET: Inheritance#Join_and_uneffecting|"Join and uneffecting"]] .) The two possible solutions follow from the previous discussions: If you do want sharing, one of the two versions must take precedence over the other. It suffices to '''undefine''' the other, and everything gets back to order. Alternatively, you can redefine both into a new version, which takes precedence over both. @@ -677,7 +676,7 @@ If you want to keep both versions, switch from sharing to replication: rename on ==Constrained genericity== -Eiffel's inheritance mechanism has an important application to extending the flexibility of the '''genericity''' mechanism. In a class SOME_CONTAINER [G], as noted in [[7 Genericity and Arrays|"Genericity and Arrays"]] ), the only operations available on entities of type G, the formal generic parameter, are those applicable to entities of all types. A generic class may, however, need to assume more about the generic parameter, as with a class SORTABLE_ARRAY [G ...] which will have a procedure sort that needs, at some stage, to perform tests of the form +Eiffel's inheritance mechanism has an important application to extending the flexibility of the '''genericity''' mechanism. In a class SOME_CONTAINER [G], as noted in [[ET: Genericity and Arrays|"Genericity and Arrays"]] ), the only operations available on entities of type G, the formal generic parameter, are those applicable to entities of all types. A generic class may, however, need to assume more about the generic parameter, as with a class SORTABLE_ARRAY [G ...] which will have a procedure sort that needs, at some stage, to perform tests of the form if item (i) < item (j) then ... @@ -699,9 +698,9 @@ Unconstrained genericity, as in C [G], is defined as equivalent to ==Assignment attempt== -The Type Conformance rule ( [[9 Inheritance#Polymorphism|"Polymorphism"]] ) ensures type safety by requiring all assignments to be from a more specific source to a more general target. +The Type Conformance rule ( [[ET: Inheritance#Polymorphism|"Polymorphism"]] ) ensures type safety by requiring all assignments to be from a more specific source to a more general target. -Sometimes you can't be sure of the source object's type. This happens for example when the object comes from the outside -- a file, a database, a network. The persistence storage mechanism( [[6 The Dynamic Structure: Execution Model#Deep_operations_and_persistence|"Deep operations and persistence"]] ) includes, along with the procedure store seen there, the reverse operation, a function retrieved which yields an object structure retrieved from a file or network, to which it was sent using store. But retrieved as declared in the corresponding class STORABLE of EiffelBase can only return the most general type, ANY; it is not possible to know its exact type until execution time, since the corresponding objects are not under the control of the retrieving system, and might even have been corrupted by some external agent. +Sometimes you can't be sure of the source object's type. This happens for example when the object comes from the outside -- a file, a database, a network. The persistence storage mechanism( [[ET: The Dynamic Structure: Execution Model#Deep_operations_and_persistence|"Deep operations and persistence"]] ) includes, along with the procedure store seen there, the reverse operation, a function retrieved which yields an object structure retrieved from a file or network, to which it was sent using store. But retrieved as declared in the corresponding class STORABLE of EiffelBase can only return the most general type, ANY; it is not possible to know its exact type until execution time, since the corresponding objects are not under the control of the retrieving system, and might even have been corrupted by some external agent. In such cases you cannot trust the declared type but must check it against the type of an actual run-time object. Eiffel introduces for this purpose the '''assignment attempt''' operation, written @@ -807,7 +806,7 @@ This means that anchored declaration are a form of of implicit covariant redecla In the example, class BUSINESS_ACCOUNT only needs to redefine the type of owner (to BUSINESS). It doesn't have to redefine set_owner except if it needs to change its implementation or assertions. -It is possible to use Current as anchor; the declaration like Current denotes a type based on the current class (with the same generic parameters if any). This is in fact a common case; we saw in [[9 Inheritance#Structural_property_classes|"Structural property classes"]] , that it applies in class COMPARABLE to features such as +It is possible to use Current as anchor; the declaration like Current denotes a type based on the current class (with the same generic parameters if any). This is in fact a common case; we saw in [[ET: Inheritance#Structural_property_classes|"Structural property classes"]] , that it applies in class COMPARABLE to features such as infix "<" (other: like Current): BOOLEAN ... @@ -821,7 +820,7 @@ Similarly, class ANY declares procedure copy as with the argument anchored to the current object. -A final, more application-oriented example of anchoring to Current is the feature merge posited in an earlier example (in [[6 The Dynamic Structure: Execution Model|"The Dynamic Structure: Execution Model"]] ) with the signature merge (other: ACCOUNT). By using instead merge (other: like Current) we can ensure that in any descendant class -- BUSINESS_ACCOUNT, SAVINGS_ACCOUNT, MINOR_ACCOUNT ... -- an account will only be mergeable with another of a compatible type. +A final, more application-oriented example of anchoring to Current is the feature merge posited in an earlier example (in [[ET: The Dynamic Structure: Execution Model|"The Dynamic Structure: Execution Model"]] ) with the signature merge (other: ACCOUNT). By using instead merge (other: like Current) we can ensure that in any descendant class -- BUSINESS_ACCOUNT, SAVINGS_ACCOUNT, MINOR_ACCOUNT ... -- an account will only be mergeable with another of a compatible type. Covariance makes static type checking more delicate; mechanisms of "system validity" and "catcalls" address the problem, discussed in detail in the book [http://eiffel.com/doc/oosc/ Object-Oriented Software Construction] (see the bibliography). diff --git a/documentation/current/method/eiffel-tutorial-et/et-learn-more.wiki b/documentation/current/method/eiffel-tutorial-et/et-learn-more.wiki index 31e00652..6702d62a 100644 --- a/documentation/current/method/eiffel-tutorial-et/et-learn-more.wiki +++ b/documentation/current/method/eiffel-tutorial-et/et-learn-more.wiki @@ -1,5 +1,4 @@ -[[Property:title|13 To Learn More]] -[[Property:link_title|ET: To Learn More]] +[[Property:title|ET: To Learn More]] [[Property:weight|-1]] [[Property:uuid|74a5c826-8f21-8cf2-4f2c-dee4ee28ead5]] Beyond this introduction, you will find the following two books essential to a mastery of the method and language:
diff --git a/documentation/current/method/eiffel-tutorial-et/et-lexical-conventions-and-style-rules.wiki b/documentation/current/method/eiffel-tutorial-et/et-lexical-conventions-and-style-rules.wiki index dd1f52e9..6ece85c2 100644 --- a/documentation/current/method/eiffel-tutorial-et/et-lexical-conventions-and-style-rules.wiki +++ b/documentation/current/method/eiffel-tutorial-et/et-lexical-conventions-and-style-rules.wiki @@ -1,5 +1,4 @@ -[[Property:title|12 Lexical Conventions and Style Rules]] -[[Property:link_title|ET: Lexical Conventions and Style Rules]] +[[Property:title|ET: Lexical Conventions and Style Rules]] [[Property:weight|-2]] [[Property:uuid|60fdf029-8626-166d-cc4f-9069aacdda7f]] Eiffel software texts are free-format: distribution into lines is not semantically significant, and any number of successive space and line-return characters is equivalent to just one space. The style rules suggest indenting software texts as illustrated by the examples in this chapter. diff --git a/documentation/current/method/eiffel-tutorial-et/et-other-mechanisms.wiki b/documentation/current/method/eiffel-tutorial-et/et-other-mechanisms.wiki index e0806c2b..8040f264 100644 --- a/documentation/current/method/eiffel-tutorial-et/et-other-mechanisms.wiki +++ b/documentation/current/method/eiffel-tutorial-et/et-other-mechanisms.wiki @@ -1,5 +1,4 @@ -[[Property:title|10 Other Mechanisms]] -[[Property:link_title|ET: Other Mechanisms]] +[[Property:title|ET: Other Mechanisms]] [[Property:weight|-4]] [[Property:uuid|c0a01664-194c-4e84-0517-8e7c1ca61dec]] We now examine a few important mechanisms that complement the preceding picture: shared objects; constants; instructions; and lexical conventions. @@ -30,7 +29,7 @@ Whatever client first calls this function will create the appropriate window and For the classes using it, console, although a function, looks very much as if it were an attribute -- only one referring to a shared object. -The "Hello World" system at the beginning of this discussion (section [[4 Hello World|4]] ) used an output instruction of the form io. put_string ( Some string ). This is another example of the general scheme illustrated by console. Feature io, declared in ANY and hence usable by all classes, is a once function that returns an object of type STANDARD_FILES (another Kernel Library class) providing access to basic input and output features, one of which is procedure put_string. Because basic input and output must all work on the same files, io should clearly be a once function, shared by all classes that need these mechanisms. +The "[[ET: Hello World|Hello World]]" system at the beginning of this discussion used an output instruction of the form io. put_string ( Some string ). This is another example of the general scheme illustrated by console. Feature io, declared in ANY and hence usable by all classes, is a once function that returns an object of type STANDARD_FILES (another Kernel Library class) providing access to basic input and output features, one of which is procedure put_string. Because basic input and output must all work on the same files, io should clearly be a once function, shared by all classes that need these mechanisms. ==Constant attributes== @@ -188,7 +187,7 @@ The design flexibility afforded by the obsolete 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|"Creating and initializing objects"]] ): +The basic forms of creation instruction, and the one most commonly used, are the two illustrated earlier ( [[ET: The Dynamic Structure: Execution Model#Creating_and_initializing_objects|"Creating and initializing objects"]] ): create x.make (2000) create x diff --git a/documentation/current/method/eiffel-tutorial-et/et-overview.wiki b/documentation/current/method/eiffel-tutorial-et/et-overview.wiki index 38cc279d..805ddf19 100644 --- a/documentation/current/method/eiffel-tutorial-et/et-overview.wiki +++ b/documentation/current/method/eiffel-tutorial-et/et-overview.wiki @@ -1,5 +1,4 @@ -[[Property:title|1 Overview]] -[[Property:link_title|ET: Overview]] +[[Property:title|ET: Overview]] [[Property:weight|-15]] [[Property:uuid|0eaddff9-5d72-87fc-663a-2fc8a9152c25]] Eiffel is a method and language for the efficient description and development of quality systems. diff --git a/documentation/current/method/eiffel-tutorial-et/et-software-process-eiffel.wiki b/documentation/current/method/eiffel-tutorial-et/et-software-process-eiffel.wiki index 07111546..95847238 100644 --- a/documentation/current/method/eiffel-tutorial-et/et-software-process-eiffel.wiki +++ b/documentation/current/method/eiffel-tutorial-et/et-software-process-eiffel.wiki @@ -1,5 +1,4 @@ -[[Property:title|3 The Software Process in Eiffel]] -[[Property:link_title|ET: The Software Process in Eiffel]] +[[Property:title|ET: The Software Process in Eiffel]] [[Property:weight|-13]] [[Property:uuid|eef7f31a-25de-93cc-9a33-41d991c51ccb]] Eiffel, as noted, supports the entire lifecycle. The underlying view of the system development lifecycle is radically different not only from the traditional "Waterfall" model (implying a sequence of discrete steps, such as analysis, global design, detailed design, implementation, separated by major changes of method and notation) but also from its more recent variants such as the spiral model or "rapid prototyping", which remain predicated on a synchronous, full-product process, and retain the gaps between successive steps. @@ -48,7 +47,7 @@ Complementing the preceding principles is the idea that, in the cluster lifecycl The preceding goals benefit from the ability to check frequently that the current iteration is correct and robust. Eiffel supports efficient compilation mechanisms through such mechanisms as the '''Melting Ice Technology''' in EiffelStudio. The Melting Ice achieves immediate recompilation after a change, guaranteeing a recompilation time that's a function of the size of the changes, not of the system's overall size. Even for a system of several thousand classes and several hundred thousand lines, the time to get restarted after a change to a few classes is, on a typical modern computer, a few seconds. -Such a "melt" (recompilation) will immediately catch (along with any syntax errors) the type errors -- often the symptoms of conceptual errors that, if left undetected, could cause grave damage later in the process or even during operation. Once the type errors have been corrected, the developers should start testing the new functionalities, relying on the power of '''assertions''' -- explained in [[8 Design by Contract (tm), Assertions and Exceptions|"Design By Contract™ Assertions, Exceptions"]] -- to kill the bugs while they are still larvae. Such extensive unit and system testing, constantly interleaved with development, plays an important part in making sure that the "current demo" is trustworthy and will eventually yield a correct and robust product. +Such a "melt" (recompilation) will immediately catch (along with any syntax errors) the type errors -- often the symptoms of conceptual errors that, if left undetected, could cause grave damage later in the process or even during operation. Once the type errors have been corrected, the developers should start testing the new functionalities, relying on the power of '''assertions''' -- explained in [[ET: Design by Contract (tm), Assertions and Exceptions|"Design By Contract™ Assertions, Exceptions"]] -- to kill the bugs while they are still larvae. Such extensive unit and system testing, constantly interleaved with development, plays an important part in making sure that the "current demo" is trustworthy and will eventually yield a correct and robust product. ==Quality and functionality== diff --git a/documentation/current/method/eiffel-tutorial-et/et-static-picture-system-organization.wiki b/documentation/current/method/eiffel-tutorial-et/et-static-picture-system-organization.wiki index 9b633b55..e2595ff4 100644 --- a/documentation/current/method/eiffel-tutorial-et/et-static-picture-system-organization.wiki +++ b/documentation/current/method/eiffel-tutorial-et/et-static-picture-system-organization.wiki @@ -1,5 +1,4 @@ -[[Property:title|5 The Static Picture: System Organization]] -[[Property:link_title|ET: The Static Picture: System Organization]] +[[Property:title|ET: The Static Picture: System Organization]] [[Property:weight|-11]] [[Property:uuid|46d3f41e-d41c-a443-4574-403dfebb60aa]] We now look at the overall organization of Eiffel software. @@ -45,7 +44,7 @@ An Eiffel class that you write does not come into a vacuum but fits in a preorda [[Image:tutorial-4]] -Any class that does not explicitly inherit from another is considered to inherit from ANY, so that every class is a descendant, direct or indirect, of ANY. ANY introduces a number of general-purpose features useful everywhere, such as copying, cloning and equality testing operations (page [[6 The Dynamic Structure: Execution Model|28]] ) and default input-output. The procedure print used in the first version of our "Hello World" (page [[4 Hello World|11]] ) comes from ANY. +Any class that does not explicitly inherit from another is considered to inherit from ANY, so that every class is a descendant, direct or indirect, of ANY. ANY introduces a number of general-purpose features useful everywhere, such as copying, cloning and equality testing operations (see [[ET: The Dynamic Structure: Execution Model|The Dynamic Structure: Execution Model]] ) and default input-output. The procedure print used in the first version of our "[[ET: Hello World|Hello World]]" comes from ANY. NONE inherits from any class that has no explicit heir. Since inheritance has no cycles, NONE cannot have proper descendants. This makes it useful, as we will see, to specify non-exported features, and to denote the type of void values. Unlike ANY, class NONE doesn't have an actual class text; instead, it's a convenient fiction. @@ -53,7 +52,7 @@ 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 (section [[3 The Software Process in Eiffel|3]] ) 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 language construct. +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 language construct. ==External software== diff --git a/documentation/current/method/eiffel-tutorial-et/index.wiki b/documentation/current/method/eiffel-tutorial-et/index.wiki index 3200910f..642e6c07 100644 --- a/documentation/current/method/eiffel-tutorial-et/index.wiki +++ b/documentation/current/method/eiffel-tutorial-et/index.wiki @@ -1,6 +1,6 @@ -[[Property:title|An Eiffel Tutorial]] +[[Property:title|An Eiffel Tutorial (ET)]] [[Property:link_title|Tutorial]] [[Property:weight|2]] [[Property:uuid|4dbc41e2-ecfc-8c50-9288-fce30f4abd90]] -From this tutorial you should get a broad understanding of what Eiffel is all about and why it is different from other technologies. Still more detail is available in [http://www.eiffel.com/doc/oosc/ 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 [http://www.eiffel.com/doc/oosc/ Object-oriented Software Construction, 2nd Edition]. diff --git a/documentation/current/method/invitation-eiffel-i2e/i2e-classes.wiki b/documentation/current/method/invitation-eiffel-i2e/i2e-classes.wiki index a856e72c..074919fe 100644 --- a/documentation/current/method/invitation-eiffel-i2e/i2e-classes.wiki +++ b/documentation/current/method/invitation-eiffel-i2e/i2e-classes.wiki @@ -1,5 +1,4 @@ -[[Property:title|4 Classes]] -[[Property:link_title|I2E: Classes]] +[[Property:title|I2E: Classes]] [[Property:weight|-11]] [[Property:uuid|218bead9-428e-f61d-1e45-7eea4291d895]] A class, it was said above, is an implementation of an abstract data type. This means that it describes a set of run-time objects, characterized by the ''' features''' (operations) applicable to them, and by the formal properties of these features. diff --git a/documentation/current/method/invitation-eiffel-i2e/i2e-combining-genericity-and-inheritance.wiki b/documentation/current/method/invitation-eiffel-i2e/i2e-combining-genericity-and-inheritance.wiki index ecf12fc9..2b15de29 100644 --- a/documentation/current/method/invitation-eiffel-i2e/i2e-combining-genericity-and-inheritance.wiki +++ b/documentation/current/method/invitation-eiffel-i2e/i2e-combining-genericity-and-inheritance.wiki @@ -1,5 +1,4 @@ -[[Property:title|12 Combining Genericity and Inheritance]] -[[Property:link_title|I2E: Combining Genericity and Inheritance]] +[[Property:title|I2E: Combining Genericity and Inheritance]] [[Property:weight|-3]] [[Property:uuid|912e4c38-9add-e478-59c3-5c10aa75d784]] Genericity and inheritance, the two fundamental mechanisms for generalizing classes, may be combined in two fruitful ways. diff --git a/documentation/current/method/invitation-eiffel-i2e/i2e-deferred-classes-and-seamless-development.wiki b/documentation/current/method/invitation-eiffel-i2e/i2e-deferred-classes-and-seamless-development.wiki index adab7596..306c1008 100644 --- a/documentation/current/method/invitation-eiffel-i2e/i2e-deferred-classes-and-seamless-development.wiki +++ b/documentation/current/method/invitation-eiffel-i2e/i2e-deferred-classes-and-seamless-development.wiki @@ -1,5 +1,4 @@ -[[Property:title|13 Deferred Classes and Seamless Development]] -[[Property:link_title|I2E: Deferred Classes and Seamless Development]] +[[Property:title|I2E: Deferred Classes and Seamless Development]] [[Property:weight|-2]] [[Property:uuid|b3264238-f160-a6fc-0b03-adcd80b1f55a]] The inheritance mechanism includes one more major notion: deferred features and classes. diff --git a/documentation/current/method/invitation-eiffel-i2e/i2e-design-contract-and-assertions.wiki b/documentation/current/method/invitation-eiffel-i2e/i2e-design-contract-and-assertions.wiki index c78dc02b..9a8e9208 100644 --- a/documentation/current/method/invitation-eiffel-i2e/i2e-design-contract-and-assertions.wiki +++ b/documentation/current/method/invitation-eiffel-i2e/i2e-design-contract-and-assertions.wiki @@ -1,5 +1,4 @@ -[[Property:title|6 Design by Contract and Assertions]] -[[Property:link_title|I2E: Design by Contract and Assertions]] +[[Property:title|I2E: Design by Contract and Assertions]] [[Property:weight|-9]] [[Property:uuid|f563aa75-3a5a-5110-b4f1-07da5448f668]] If classes are to deserve their definition as abstract data type implementations, they must be known not just by the available operations, but also by the formal properties of these operations, which did not yet appear in the preceding example. @@ -134,7 +133,7 @@ feature end -- ACCOUNT -This is not actual Eiffel, only documentation of Eiffel classes, hence the use of slightly different syntax to avoid any confusion ( interface class rather than class). In accordance with the Uniform Access Principle (page [[4 Classes|7]] ), the output for balance 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 ( interface class rather than class). In accordance with the Uniform Access Principle (in [[I2E: Classes|Classes]]), the output for balance 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. diff --git a/documentation/current/method/invitation-eiffel-i2e/i2e-design-principles.wiki b/documentation/current/method/invitation-eiffel-i2e/i2e-design-principles.wiki index 55bda873..0c9246c0 100644 --- a/documentation/current/method/invitation-eiffel-i2e/i2e-design-principles.wiki +++ b/documentation/current/method/invitation-eiffel-i2e/i2e-design-principles.wiki @@ -1,5 +1,4 @@ -[[Property:title|2 Design Principles]] -[[Property:link_title|I2E: Design Principles]] +[[Property:title|I2E: Design Principles]] [[Property:weight|-13]] [[Property:uuid|529659bd-ec13-5805-87f2-2fd9318ad442]] The aim of Eiffel is to help specify, design, implement and modify quality software. This goal of quality in software is a combination of many factors; the language design concentrated on the three factors which, in the current state of the industry, are in direct need of improvements: reusability, extendibility and reliability. Also important were other factors such as efficiency, openness and portability. diff --git a/documentation/current/method/invitation-eiffel-i2e/i2e-event-driven-programming-and-agents.wiki b/documentation/current/method/invitation-eiffel-i2e/i2e-event-driven-programming-and-agents.wiki index 193fa6b5..c7e7b9cb 100644 --- a/documentation/current/method/invitation-eiffel-i2e/i2e-event-driven-programming-and-agents.wiki +++ b/documentation/current/method/invitation-eiffel-i2e/i2e-event-driven-programming-and-agents.wiki @@ -1,5 +1,4 @@ -[[Property:title|8 Event-Driven Programming and Agents]] -[[Property:link_title|I2E: Event-Driven Programming and Agents]] +[[Property:title|I2E: Event-Driven Programming and Agents]] [[Property:weight|-7]] [[Property:uuid|16fdab60-ae42-1bb8-f4bb-89e34d18a842]] The division of roles in object technology is clear: of the two principal constituents of a system, object types and operations, the first dominates. Classes, representing object types, determines the structure of the software; every routine, representing an operations, belongs to a class. diff --git a/documentation/current/method/invitation-eiffel-i2e/i2e-exceptions.wiki b/documentation/current/method/invitation-eiffel-i2e/i2e-exceptions.wiki index b671cfb5..5668d427 100644 --- a/documentation/current/method/invitation-eiffel-i2e/i2e-exceptions.wiki +++ b/documentation/current/method/invitation-eiffel-i2e/i2e-exceptions.wiki @@ -1,5 +1,4 @@ -[[Property:title|7 Exceptions]] -[[Property:link_title|I2E: Exceptions]] +[[Property:title|I2E: Exceptions]] [[Property:weight|-8]] [[Property:uuid|e3e10dac-0dd7-bbe1-240c-6a6985c7376a]] Whenever there is a contract, the risk exists that someone will break it. This is where exceptions come in. diff --git a/documentation/current/method/invitation-eiffel-i2e/i2e-genericity.wiki b/documentation/current/method/invitation-eiffel-i2e/i2e-genericity.wiki index c1527196..136d1b43 100644 --- a/documentation/current/method/invitation-eiffel-i2e/i2e-genericity.wiki +++ b/documentation/current/method/invitation-eiffel-i2e/i2e-genericity.wiki @@ -1,5 +1,4 @@ -[[Property:title|9 Genericity]] -[[Property:link_title|I2E: Genericity]] +[[Property:title|I2E: Genericity]] [[Property:weight|-6]] [[Property:uuid|091c0b65-73de-b454-b3f2-d8752983780e]] Building software components (classes) as implementations of abstract data types yields systems with a solid architecture but does not in itself ensure reusability and extendibility. Two key techniques address the problem: generosity (unconstrained or constrained) and inheritance. Let us look first at the unconstrained form. diff --git a/documentation/current/method/invitation-eiffel-i2e/i2e-inheritance.wiki b/documentation/current/method/invitation-eiffel-i2e/i2e-inheritance.wiki index 925d0190..b9045767 100644 --- a/documentation/current/method/invitation-eiffel-i2e/i2e-inheritance.wiki +++ b/documentation/current/method/invitation-eiffel-i2e/i2e-inheritance.wiki @@ -1,5 +1,4 @@ -[[Property:title|10 Inheritance]] -[[Property:link_title|I2E: Inheritance]] +[[Property:title|I2E: Inheritance]] [[Property:weight|-5]] [[Property:uuid|acf84989-0e7c-f2f7-427a-19e7fce404ce]] Inheritance, the other fundamental generalization mechanism, makes it possible to define a new class by combination and specialization of existing classes rather than from scratch. diff --git a/documentation/current/method/invitation-eiffel-i2e/i2e-invitation-eiffel-copyright.wiki b/documentation/current/method/invitation-eiffel-i2e/i2e-invitation-eiffel-copyright.wiki index 633463d7..a6f9d664 100644 --- a/documentation/current/method/invitation-eiffel-i2e/i2e-invitation-eiffel-copyright.wiki +++ b/documentation/current/method/invitation-eiffel-i2e/i2e-invitation-eiffel-copyright.wiki @@ -1,5 +1,4 @@ -[[Property:title|Invitation to Eiffel Copyright]] -[[Property:link_title|I2E: Invitation to Eiffel Copyright]] +[[Property:title|I2E: Invitation to Eiffel Copyright]] [[Property:weight|0]] [[Property:uuid|ce7b4af4-b669-9fec-92e1-c24c4f089336]] Title: Invitation to Eiffel, Eiffel Software Technical Report TR-EI-67/IV. diff --git a/documentation/current/method/invitation-eiffel-i2e/i2e-object-oriented-design.wiki b/documentation/current/method/invitation-eiffel-i2e/i2e-object-oriented-design.wiki index 259ef648..2ee7b3fc 100644 --- a/documentation/current/method/invitation-eiffel-i2e/i2e-object-oriented-design.wiki +++ b/documentation/current/method/invitation-eiffel-i2e/i2e-object-oriented-design.wiki @@ -1,5 +1,4 @@ -[[Property:title|3 Object-Oriented Design]] -[[Property:link_title|I2E: Object-Oriented Design]] +[[Property:title|I2E: Object-Oriented Design]] [[Property:weight|-12]] [[Property:uuid|e0a1f24e-5dd7-e5f8-8be8-8da32cc6a91c]] To achieve reusability, extendibility and reliability, the principles of object-oriented design provide the best known technical answer. diff --git a/documentation/current/method/invitation-eiffel-i2e/i2e-polymorphism-and-dynamic-binding.wiki b/documentation/current/method/invitation-eiffel-i2e/i2e-polymorphism-and-dynamic-binding.wiki index 3f2c0be6..1e3ed292 100644 --- a/documentation/current/method/invitation-eiffel-i2e/i2e-polymorphism-and-dynamic-binding.wiki +++ b/documentation/current/method/invitation-eiffel-i2e/i2e-polymorphism-and-dynamic-binding.wiki @@ -1,5 +1,4 @@ -[[Property:title|11 Polymorphism and Dynamic Binding]] -[[Property:link_title|I2E: Polymorphism and Dynamic Binding]] +[[Property:title|I2E: Polymorphism and Dynamic Binding]] [[Property:weight|-4]] [[Property:uuid|1c3221be-0237-1c9a-407d-652a4084de12]] Inheritance is not just a module combination and enrichment mechanism. It also enables the definition of flexible entities that may become attached to objects of various forms at run time, a property known as polymorphism. diff --git a/documentation/current/method/invitation-eiffel-i2e/i2e-putting-system-together.wiki b/documentation/current/method/invitation-eiffel-i2e/i2e-putting-system-together.wiki index 01e0560b..05baa13d 100644 --- a/documentation/current/method/invitation-eiffel-i2e/i2e-putting-system-together.wiki +++ b/documentation/current/method/invitation-eiffel-i2e/i2e-putting-system-together.wiki @@ -1,5 +1,4 @@ -[[Property:title|14 Putting a System Together]] -[[Property:link_title|I2E: Putting a System Together]] +[[Property:title|I2E: Putting a System Together]] [[Property:weight|-1]] [[Property:uuid|97460714-8ae1-a7cb-8216-235827045ea6]] We have now studied the constituents of Eiffel software. It remains to see how you can combine these elements into executable '''systems''' (the Eiffel concept closest to the traditional notion of program) and libraries. diff --git a/documentation/current/method/invitation-eiffel-i2e/i2e-types.wiki b/documentation/current/method/invitation-eiffel-i2e/i2e-types.wiki index 6ba332da..005c69b9 100644 --- a/documentation/current/method/invitation-eiffel-i2e/i2e-types.wiki +++ b/documentation/current/method/invitation-eiffel-i2e/i2e-types.wiki @@ -1,12 +1,11 @@ -[[Property:title|5 Types]] -[[Property:link_title|I2E: Types]] +[[Property:title|I2E: Types]] [[Property:weight|-10]] [[Property:uuid|344a9fdc-3346-5e2d-5fdd-77464e92f72f]] Eiffel is strongly typed for readability and reliability. Every entity is declared of a certain type, which may be either a reference type or an expanded type. Any type T is based on a class, which defines the operations that will be applicable to instances of T. The difference between the two categories of type affects the semantics of an entity x declared of type T: for a reference type, the most common case, possible values for x are references to objects; for an expanded type, the values are objects. In both cases, the type rules guarantee that the objects will be instances of T. -A non-expanded class such as ACCOUNT yields a reference type. As a result, an entity of type ACCOUNT, such as acc in the earlier client example (see the declaration of acc and the accompanying picture as given in [[4 Classes|section 4]] ), denotes possible run-time references to objects of type ACCOUNT. +A non-expanded class such as ACCOUNT yields a reference type. As a result, an entity of type ACCOUNT, such as acc in the earlier client example (see the declaration of acc and the accompanying picture as given in [[I2E: Classes]] ), denotes possible run-time references to objects of type ACCOUNT. In contrast, the value of an entity acc declared of type expanded ACCOUNT is an object such as the one shown on the figure below, with no reference. The only difference with the earlier figure is that the value of acc is now an ACCOUNT object, not a reference to such an object. No creation instruction is needed in this case. (The figure does not show the PERSON object to which the owner field of the ACCOUNT object -- itself a reference -- is attached.) diff --git a/documentation/current/method/invitation-eiffel-i2e/i2e-what-must-i-know-first.wiki b/documentation/current/method/invitation-eiffel-i2e/i2e-what-must-i-know-first.wiki index b9e19c6d..a40b4903 100644 --- a/documentation/current/method/invitation-eiffel-i2e/i2e-what-must-i-know-first.wiki +++ b/documentation/current/method/invitation-eiffel-i2e/i2e-what-must-i-know-first.wiki @@ -1,5 +1,4 @@ -[[Property:title|What Must I Know First?]] -[[Property:link_title|I2E: What Must I Know First?]] +[[Property:title|I2E: What Must I Know First?]] [[Property:weight|-14]] [[Property:uuid|f40b4a30-87f7-2c27-b6e7-ef2f2a74661b]] This Invitation assumes that you have some experience of software development, but that's all. Previous exposure to object technology is not required. If you've had it, it will help; but if it has all been to notations like UML or programming languages like C++ and Java, you should not let it guide your study of this Invitation. Although Eiffel shares a number of properties with these other approaches, it takes a fresh path to object technology, based on a small number of simple, far-reaching concepts. diff --git a/documentation/current/method/invitation-eiffel-i2e/index.wiki b/documentation/current/method/invitation-eiffel-i2e/index.wiki index d2e6e016..ad06e3be 100644 --- a/documentation/current/method/invitation-eiffel-i2e/index.wiki +++ b/documentation/current/method/invitation-eiffel-i2e/index.wiki @@ -1,5 +1,6 @@ -[[Property:title|Invitation to Eiffel]] +[[Property:title|Invitation to Eiffel (I2E)]] +[[Property:link_title|Invitation to Eiffel]] [[Property:weight|-15]] [[Property:uuid|7a606387-2653-b122-b4ef-e283a389656e]] -The Invitation to Eiffel is a short set of pages that should provide you with the essence of the Eiffel way, without taking too much of your time. Enjoy this profoundly different way of thinking about developing software! When you are done, move on to the more detailed Eiffel tutorial. +The Invitation to Eiffel (I2E) is a short set of pages that should provide you with the essence of the Eiffel way, without taking too much of your time. Enjoy this profoundly different way of thinking about developing software! When you are done, move on to the more detailed Eiffel tutorial. diff --git a/documentation/current/platform-specifics/microsoft-windows/wel/wel-samples/hello-world.wiki b/documentation/current/platform-specifics/microsoft-windows/wel/wel-samples/hello-world.wiki index 7d8eb76b..4be0d825 100644 --- a/documentation/current/platform-specifics/microsoft-windows/wel/wel-samples/hello-world.wiki +++ b/documentation/current/platform-specifics/microsoft-windows/wel/wel-samples/hello-world.wiki @@ -1,5 +1,4 @@ -[[Property:title|Hello World]] -[[Property:link_title|Hello World!]] +[[Property:title|Hello World!]] [[Property:weight|-4]] [[Property:uuid|37b82651-78e9-dd6a-97bf-0fe3c444157d]] [[Image:hello|hello]]
diff --git a/documentation/current/solutions/gui-building/eiffelvision-2/eiffelvision-library-reference-manual/events.wiki b/documentation/current/solutions/gui-building/eiffelvision-2/eiffelvision-library-reference-manual/events.wiki index ad5c4efc..43454bfa 100644 --- a/documentation/current/solutions/gui-building/eiffelvision-2/eiffelvision-library-reference-manual/events.wiki +++ b/documentation/current/solutions/gui-building/eiffelvision-2/eiffelvision-library-reference-manual/events.wiki @@ -9,7 +9,7 @@ An event is considered to be an external action that occurs during a program's e ==How do I connect to an event?== -Every widget and item has an action sequence associated with it that relates to some kind of event. For example an [[ref:libraries/vision2/reference/ev_button_chart|EV_BUTTON]] has a select_actions action sequence. This gets fired when the user clicks/selects the button. To have a procedure called on this event, you need to create an agent based on this procedure, and then add this to the action sequence (via extend). For a more detailed description of agents and their uses click [[11 Agents|here]] . +Every widget and item has an action sequence associated with it that relates to some kind of event. For example an [[ref:libraries/vision2/reference/ev_button_chart|EV_BUTTON]] has a select_actions action sequence. This gets fired when the user clicks/selects the button. To have a procedure called on this event, you need to create an agent based on this procedure, and then add this to the action sequence (via extend). For a more detailed description of agents and their uses click [[ET: Agents|here]] . An example of adding an agent to an action_sequence is as follows. diff --git a/documentation/current/why-eiffel/eiffel-two-minute-fact-sheet.wiki b/documentation/current/why-eiffel/eiffel-two-minute-fact-sheet.wiki index c77e4f87..53a58942 100644 --- a/documentation/current/why-eiffel/eiffel-two-minute-fact-sheet.wiki +++ b/documentation/current/why-eiffel/eiffel-two-minute-fact-sheet.wiki @@ -87,7 +87,7 @@ Eiffel consists of: **Government and national defense **Science -For a more detailed overview see [[Invitation to Eiffel|An Invitation to Eiffel]] . +For a more detailed overview see [[Invitation to Eiffel (I2E)|An Invitation to Eiffel]] .