mirrors/eiffel-org
1
0
Fork 0
mirror of https://github.com/EiffelSoftware/eiffel-org.git synced 2026-02-07 11:04:06 +01:00
Code Issues Packages Projects Releases Wiki Activity

Updated to upcoming 23.09

Browse Source 
git-svn-id: https://svn.eiffel.com/eiffel-org/trunk@2393 abb3cda0-5349-4a8f-a601-0c33ac3a8c38
This commit is contained in:
eifops
2023-09-25 09:13:12 +00:00
parent 246745930d
commit e2bb303f94
2975 changed files with 63910 additions and 342 deletions
Download Patch File Download Diff File Expand all files Collapse all files

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

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

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

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

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

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

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

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

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

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

4
documentation/trunk/eiffel/Tutorials/eiffel-tutorial-et/index.wiki
View File

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