mirrors/eiffel-org
1
0
Fork 0
mirror of https://github.com/EiffelSoftware/eiffel-org.git synced 2025-12-07 23:32:42 +01:00
Code Issues Packages Projects Releases Wiki Activity

merge changes from branch 17.05 onto trunk

Browse Source 
git-svn-id: https://svn.eiffel.com/eiffel-org/trunk@1941 abb3cda0-5349-4a8f-a601-0c33ac3a8c38
This commit is contained in:
eiffel-org
2018-02-06 13:41:39 +00:00
parent 0b47147042
commit 265a446dab
14 changed files with 293 additions and 307 deletions
Download Patch File Download Diff File Expand all files Collapse all files

6
documentation/trunk/eiffel/Tutorials/eiffel-tutorial-et/et-agents.wiki
View File

@@ -51,7 +51,7 @@ Among the features of <code>ROUTINE</code> and its descendants the most importan
As an example of using these mechanisms, here is how the function <code>integral</code> could look like in our <code>INTEGRATOR</code> example class. The details of the integration algorithm (straight forward, and making no claims to numerical sophistication) do not matter, but you see the place were we evaluate the mathematical function associated with <code>f</code>, by calling <code>item</code> on <code>f</code>:
<code>
integral (f: FUNCTION [ANY, TUPLE [REAL], REAL]; low, high: REAL): REAL
integral (f: FUNCTION [TUPLE [REAL], REAL]; low, high: REAL): REAL
-- Integral of `f' over the interval [`low', `high']
require
meaningful_interval: low <= high
@@ -120,7 +120,7 @@ In the agent <code>agent record_city (name, population, ?, ?)</code>, we say tha
For type checking, <code>agent record_city (name, population, ?, ?)</code> and <code>agent your_routine (?, ?)</code> are acceptable in exactly the same situations, since both represent routines with two arguments. The type of both is
<code>
PROCEDURE [ANY, TUPLE [INTEGER, INTEGER]]
PROCEDURE [TUPLE [INTEGER, INTEGER]]
</code>
where the tuple type specifies the open operands.
@@ -241,6 +241,8 @@ Inline agents are interesting also as an implementation of the notion of [http:/
Agents provide a welcome complement to the other mechanisms of Eiffel. They do not conflict with them but, when appropriate -- as in the examples sketched in this section -- provide clear and expressive programming schemes, superior to the alternatives.
Compatibility note: earlier versions of the agent classes (ROUTINE, PROCEDURE, FUNCTION, PREDICATE) had an extra initial generic parameter, for which ANY was generally used. The compiler has been engineered to accept the old style in most cases.
{{SeeAlso|[[Event Programming with Agents]] }}

2
documentation/trunk/eiffel/Tutorials/invitation-eiffel-i2e/i2e-classes.wiki
View File

@@ -7,7 +7,7 @@ Such objects are called the '''direct instances''' of the class. Classes and obj
{{info|"Object-Oriented" is a misnomer; "Class-Oriented Analysis, Design and Programming" would be a more accurate description of the method. }}
To see what a class looks like, let us look at a simple example, <code>ACCOUNT</code>, which describes bank accounts. But before exploring the class itself it is useful to study how it maybe used by other classes, called its '''clients'''.
To see what a class looks like, let us look at a simple example, <code>ACCOUNT</code>, which describes bank accounts. But before exploring the class itself it is useful to study how it may be used by other classes, called its '''clients'''.
A class <code>X</code> may become a client of <code>ACCOUNT</code> by declaring one or more '''entities''' of type <code>ACCOUNT</code>. Such a declaration is of the form:
<code>acc: ACCOUNT</code>

2
documentation/trunk/eiffel/Tutorials/invitation-eiffel-i2e/i2e-design-contract-and-assertions.wiki
View File

@@ -143,7 +143,7 @@ Under EiffelStudio you may also set up compilation options, for the whole system
This ability to check assertions provides a powerful testing and debugging mechanism, in particular because the classes of the EiffelBase Libraries, widely used in Eiffel software development, are protected by carefully written assertions.
Run-time monitoring, however, is only one application of assertions, whose role as design and documentation aids, as part of theory of Design by Contract&#153;, exerts a pervasive influence on the Eiffel style of software development.
Run-time monitoring, however, is only one application of assertions, whose role as design and documentation aids, as part of the theory of Design by Contract&#153;, exerts a pervasive influence on the Eiffel style of software development.

2
documentation/trunk/eiffel/Tutorials/invitation-eiffel-i2e/i2e-event-driven-programming-and-agents.wiki
View File

@@ -1,7 +1,7 @@
[[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.
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 operation, belongs to a class.
In some circumstances it is useful to define an object that denotes an operation. This is especially useful if you want to build an object structure that refers to operations, so that you can later traverse the structure and execute the operations encountered. A typical application is '''event-driven programming''' for Graphical User Interfaces (GUI), including Web programming. In GUI programming you will want to record properties of the form
<code>