mirror of
https://github.com/EiffelSoftware/eiffel-org.git
synced 2025-12-07 15:22:31 +01:00
merge changes from branch 17.05 onto trunk
git-svn-id: https://svn.eiffel.com/eiffel-org/trunk@1941 abb3cda0-5349-4a8f-a601-0c33ac3a8c38
This commit is contained in:
eiffel-org
@@ -55,7 +55,7 @@ Another thought might be that we could just have the compiler do all the work fo
|
||||
|
||||
So, all of this boils down to the fact that we have to take some actions that help the compiler along. That's what the following are about.
|
||||
|
||||
===Certified Attachment Patterns (CAPs)===
|
||||
==Certified Attachment Patterns (CAPs)==
|
||||
|
||||
We know that in the context of certain code patterns, it is clear that it would be impossible for a reference to be void. These patterns are identified and we call them CAPs, short for Certified Attachment Patterns. Here is a very straightforward example expressed in a syntax that should be familiar to all Eiffel developers:
|
||||
<code>
|
||||
@@ -73,7 +73,7 @@ It is important to understand that in this example (and with other CAPs), <code>
|
||||
{{note|You will find more useful information about CAPs in [[Creating a new void-safe project#More about CAPs|More about CAPs]]. Learn how certain code patterns are determined to be CAPs in [[What makes a Certified Attachment Pattern]]. }}
|
||||
|
||||
|
||||
===The ''attached syntax'' (object test)===
|
||||
==The ''attached syntax'' (object test)==
|
||||
|
||||
For the purposes of void-safety, the '''attached syntax''' does double duty for us. It allows us to make certain that a reference is attached, and it provides us a safe way to access objects that are attached to class attributes.
|
||||
|
||||
@@ -100,7 +100,7 @@ In the example above, <code>x</code> is tested to make certain that it is attach
|
||||
|
||||
One way to make sure we comply with the target rule would be always use a CAP or the attached syntax every time we want to apply a feature to a referenced object. That might work, but it falls among the impractical approaches to the problem ... it would break a very high percentage of existing Eiffel code, not to mention cluttering things up quite a bit.
|
||||
|
||||
===Types as "attached" or "detachable"===
|
||||
==Types as "attached" or "detachable"==
|
||||
|
||||
Rather than trying to protect every feature call, Eiffel allows us to declare any variable as being of an '''attached type'''. This is an important extension to the Eiffel type system.
|
||||
|
||||
@@ -126,7 +126,7 @@ This doesn't mean that on every declaration you must put either an ''attached ma
|
||||
|
||||
In Eiffel then, all declarations will have types that are either '''attached''' or '''detachable'''. As a result, we need only use CAPs and the attached syntax with detachable types. So the important thing to remember is that ''direct access to class attributes of detachable types is never void-safe.''
|
||||
|
||||
====Attachment and conformance====
|
||||
===Attachment and conformance===
|
||||
|
||||
The distinction between attached and detachable types results in a small but important addition to the rules of conformance. Because variables declared as attached types can never be void, then it is important not to allow any assignment of a detachable source to an attached target. However, assigning an attached source to a detachable target is permissible. The following code shows both cases (as described earlier, class types are attached by default).
|
||||
<code>
|
||||
@@ -140,7 +140,7 @@ The distinction between attached and detachable types results in a small but imp
|
||||
</code>
|
||||
|
||||
|
||||
===Initialization rule===
|
||||
==Initialization rule==
|
||||
|
||||
If we have attached types, then we can assume variables declared of these types, once attached, will always be attached. But how do they get attached in the first place? That's what the initialization rule is all about.
|
||||
|
||||
@@ -173,7 +173,7 @@ Still, it's not too hard to understand the basics of initializing variables of a
|
||||
|
||||
* A variable is considered properly set if it is '''self-initializing'''. What it means to be self-initializing is explained below.
|
||||
|
||||
===Self-initializing attributes===
|
||||
==Self-initializing attributes==
|
||||
|
||||
A self-initializing attribute is guaranteed to have a value when accessed at run time. Declarations of self-initializing attributes are characterized by the use of the code that follows the <code>attribute</code> keyword. The code is executed to initialize the attribute in the case that the attribute is accessed prior to being initialized in any other way.
|
||||
|
||||
@@ -188,7 +188,7 @@ So, self-initializing attributes are ordinary attributes, with the restriction t
|
||||
|
||||
In the example above, the attribute <code>value</code> will be attached to an object of type <code>STRING</code>, in fact, the empty string, if no other initialization occurs before the first access of <code>value</code>.
|
||||
|
||||
===Rule for conformance===
|
||||
==Rule for conformance==
|
||||
|
||||
You will remember that the Eiffel type system dictates that an assignment instruction:
|
||||
<code>
|
||||
@@ -206,7 +206,7 @@ The same goes for routine calls. In a call:
|
||||
</code>
|
||||
where <code>x</code> is the formal argument for <code>r</code>, then if x is of an attached type, then y must be of an attached type.
|
||||
|
||||
===Stable attributes===
|
||||
==Stable attributes==
|
||||
|
||||
Stable attributes are really stable ''detachable'' attributes, as adding the concept of stability is meaningful only for detachable attributes. Declaring a detachable attribute as stable, means that it behaves like a detachable attribute except that its assignment rules mimic those of attached attributes. In other words, a stable attribute does not need to be attached during object creation the way that attributes declared as attached must. But like attached type attributes, stable attributes can never be the target of an assignment in which the source is <code>Void</code> or a detachable type.
|
||||
<code>
|
||||
@@ -221,7 +221,7 @@ This means that even though stable attributes do not need to be initialized like
|
||||
|
||||
Stable attributes are also interesting in that they are the only exception to the rule given above in the [[Void-safety: Background, definition, and tools#Certified Attachment Patterns (CAPs)|CAPs section]] that stated that direct access to attributes cannot be protected by a CAP. A stable attribute can be used under the protection of a CAP. This is because once a stable attribute has an object attached, it can never again be set to <code>Void</code>. So there's no worry about having the attribute's state going unexpectedly from attached to non-attached because of the actions of other routines or threads.
|
||||
|
||||
===Rule for generic parameters===
|
||||
==Rule for generic parameters==
|
||||
|
||||
Generic classes provide another question. A generic class like
|
||||
<code>
|
||||
@@ -265,7 +265,7 @@ class C [G -> attached ANY]
|
||||
</code>
|
||||
then <code>x</code> in this class <code>G</code> represents an attached type. Consequently, the actual generic type in any derivation must be attached ... and feature calls on <code>x</code> are safe.
|
||||
|
||||
===Rule for ARRAYs===
|
||||
==Rule for ARRAYs==
|
||||
|
||||
The rule for generic parameters applies to all generic types ... except <code>ARRAYs</code>. In the typical creation of an <code>ARRAY</code>, we would provide a minimum and maximum index.
|
||||
<code>
|
||||
@@ -285,7 +285,3 @@ The first argument is an object of the actual generic type, in this case an empt
|
||||
|
||||
|
||||
For more detail on void-safe use of arrays and other generic classes, see the section: [[Creating a new void-safe project#Using generic classes|Using generic classes]].
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
@@ -1,97 +1,97 @@
|
||||
[[Property:title|Two-Minute fact sheet]]
|
||||
[[Property:weight|0]]
|
||||
[[Property:uuid|f672bfb8-ddea-beb1-eaa6-e374a6a6bc92]]
|
||||
If you are both curious about Eiffel and in a hurry, take a couple of minutes to read these facts about Eiffel. If anything here seems too good to be true, please suspend your disbelief. Press on to the more detailed documentation for the rationale, and our success stories for the evidence behind these facts.
|
||||
|
||||
===Eiffel is the most comprehensive approach to the construction of successful object-oriented software.===
|
||||
|
||||
Software produced with Eiffel is typically:
|
||||
|
||||
*Cheaper -- You spend less on development, debugging, maintenance
|
||||
*Better -- You get the bugs before they get you
|
||||
*Shorter time-to-market -- You release quality products ahead of your competitors
|
||||
*Easier -- In every way: understanding, maintenance, reuse, and extension
|
||||
|
||||
===Systems developed using Eiffel can be made portable across major industry platforms.===
|
||||
|
||||
*Windows NT/2000/XP/Vista including CLS compliance on Microsoft .NET
|
||||
*Major Unix versions
|
||||
*Macintosh OS X
|
||||
*Linux
|
||||
*OpenVMS
|
||||
|
||||
===Eiffel is the only approach that covers analysis, design, implementation and maintenance in a single framework.===
|
||||
|
||||
Eiffel consists of:
|
||||
|
||||
====The Eiffel Method====
|
||||
|
||||
*Is Based on a small number of powerful ideas from computer science and software engineering
|
||||
**An example of these is Design by Contract
|
||||
***Defines a software system as a set of components interacting through precisely specified contracts
|
||||
***Contracts are active and enforceable throughout the life-cycle
|
||||
***Design by Contract promotes:
|
||||
****Precise software specification
|
||||
****Software reliability
|
||||
****Safe, effective software reuse
|
||||
*Uses a "single-product" model
|
||||
**All life-cycle phases are supported by a single notation
|
||||
***No need to switch, say, from "analysis language" to "design language"
|
||||
**Products of all phases are recorded in a single document with multiple views
|
||||
|
||||
====The Eiffel Programming Language====
|
||||
|
||||
*Exists to express the products of the Eiffel Method
|
||||
*Supports features not always available in competing technologies
|
||||
**Contracts and contract monitoring
|
||||
**Exception handling based on software specification (versus ad hoc try/catch)
|
||||
**Void-safety: calls on void (null) references are eliminated at compile time
|
||||
**Inheritance
|
||||
***Includes multiple and repeated inheritance
|
||||
***Safe and fully controllable
|
||||
**Genericity (generic classes), including constrained genericity
|
||||
**Platform independent concurrency ([[Concurrent programming with SCOOP|SCOOP]])
|
||||
*Widely recognized as simultaneously the simplest and most complete implementation of object-oriented concepts
|
||||
*Is clean, elegant, readable, easy to learn
|
||||
|
||||
|
||||
====EiffelStudio and the Eiffel Libraries====
|
||||
|
||||
*'''EiffelStudio'''
|
||||
**Runs on all major platforms (of course, it's built with Eiffel)
|
||||
**Features lightning-fast compilation (Melting Ice Technology)
|
||||
**Generates lightning-fast executables
|
||||
***Final compilation generates standard C (MSIL in the case of .NET)
|
||||
***Speed of executables rivals native C
|
||||
**Provides multiple views of your product
|
||||
***Views for different life-cycle phases and developer roles
|
||||
***Graphical views
|
||||
**Features automated generation HTML and XML documentation
|
||||
|
||||
*'''The Eiffel Libraries'''
|
||||
**Contain rich, time-tested, multi-platform components
|
||||
**Include facilities for
|
||||
***GUI building and graphics
|
||||
***Web
|
||||
***Networking
|
||||
***Fundamental algorithms and data structures
|
||||
***Object persistence and database access
|
||||
***Multi-threading
|
||||
***Lexical analysis and parsing
|
||||
***Interfacing with other technologies
|
||||
|
||||
===Eiffel has a proven track record of successful projects===
|
||||
|
||||
*Some of the largest successful object-oriented projects ever built, including systems target to:
|
||||
**Finance and securities
|
||||
**Education
|
||||
**Trading
|
||||
**Manufacturing
|
||||
**Telecommunications
|
||||
**Government and national defense
|
||||
**Science
|
||||
|
||||
For a more detailed overview see [[Invitation to Eiffel (I2E)|An Invitation to Eiffel]] .
|
||||
|
||||
|
||||
|
||||
[[Property:title|Two-Minute fact sheet]]
|
||||
[[Property:weight|0]]
|
||||
[[Property:uuid|f672bfb8-ddea-beb1-eaa6-e374a6a6bc92]]
|
||||
If you are both curious about Eiffel and in a hurry, take a couple of minutes to read these facts about Eiffel. If anything here seems too good to be true, please suspend your disbelief. Press on to the more detailed documentation for the rationale, and our success stories for the evidence behind these facts.
|
||||
|
||||
===Eiffel is the most comprehensive approach to the construction of successful object-oriented software.===
|
||||
|
||||
Software produced with Eiffel is typically:
|
||||
|
||||
*Cheaper -- You spend less on development, debugging, maintenance
|
||||
*Better -- You get the bugs before they get you
|
||||
*Shorter time-to-market -- You release quality products ahead of your competitors
|
||||
*Easier -- In every way: understanding, maintenance, reuse, and extension
|
||||
|
||||
===Systems developed using Eiffel can be made portable across major industry platforms.===
|
||||
|
||||
*Windows NT/2000/XP/Vista including CLS compliance on Microsoft .NET
|
||||
*Major Unix versions
|
||||
*Macintosh OS X
|
||||
*Linux
|
||||
*OpenVMS
|
||||
|
||||
===Eiffel is the only approach that covers analysis, design, implementation and maintenance in a single framework.===
|
||||
|
||||
Eiffel consists of:
|
||||
|
||||
====The Eiffel Method====
|
||||
|
||||
*Is Based on a small number of powerful ideas from computer science and software engineering
|
||||
**An example of these is Design by Contract
|
||||
***Defines a software system as a set of components interacting through precisely specified contracts
|
||||
***Contracts are active and enforceable throughout the life-cycle
|
||||
***Design by Contract promotes:
|
||||
****Precise software specification
|
||||
****Software reliability
|
||||
****Safe, effective software reuse
|
||||
*Uses a "single-product" model
|
||||
**All life-cycle phases are supported by a single notation
|
||||
***No need to switch, say, from "analysis language" to "design language"
|
||||
**Products of all phases are recorded in a single document with multiple views
|
||||
|
||||
====The Eiffel Programming Language====
|
||||
|
||||
*Exists to express the products of the Eiffel Method
|
||||
*Supports features not always available in competing technologies
|
||||
**Contracts and contract monitoring
|
||||
**Exception handling based on software specification (versus ad hoc try/catch)
|
||||
**Void-safety: calls on void (null) references are eliminated at compile time
|
||||
**Inheritance
|
||||
***Includes multiple and repeated inheritance
|
||||
***Safe and fully controllable
|
||||
**Genericity (generic classes), including constrained genericity
|
||||
**Platform independent concurrency ([[Concurrent programming with SCOOP|SCOOP]])
|
||||
*Widely recognized as simultaneously the simplest and most complete implementation of object-oriented concepts
|
||||
*Is clean, elegant, readable, easy to learn
|
||||
|
||||
|
||||
====EiffelStudio and the Eiffel Libraries====
|
||||
|
||||
*'''EiffelStudio'''
|
||||
**Runs on all major platforms (of course, it's built with Eiffel)
|
||||
**Features lightning-fast compilation (Melting Ice Technology)
|
||||
**Generates lightning-fast executables
|
||||
***Final compilation generates standard C (MSIL in the case of .NET)
|
||||
***Speed of executables rivals native C
|
||||
**Provides multiple views of your product
|
||||
***Views for different life-cycle phases and developer roles
|
||||
***Graphical views
|
||||
**Features automated generation of HTML and XML documentation
|
||||
|
||||
*'''The Eiffel Libraries'''
|
||||
**Contain rich, time-tested, multi-platform components
|
||||
**Include facilities for
|
||||
***GUI building and graphics
|
||||
***Web
|
||||
***Networking
|
||||
***Fundamental algorithms and data structures
|
||||
***Object persistence and database access
|
||||
***Multi-threading
|
||||
***Lexical analysis and parsing
|
||||
***Interfacing with other technologies
|
||||
|
||||
===Eiffel has a proven track record of successful projects===
|
||||
|
||||
*Some of the largest successful object-oriented projects ever built, including systems target to:
|
||||
**Finance and securities
|
||||
**Education
|
||||
**Trading
|
||||
**Manufacturing
|
||||
**Telecommunications
|
||||
**Government and national defense
|
||||
**Science
|
||||
|
||||
For a more detailed overview see [[Invitation to Eiffel (I2E)|An Invitation to Eiffel]] .
|
||||
|
||||
|
||||
|
||||
|
||||
@@ -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]] }}
|
||||
|
||||
|
||||
@@ -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>
|
||||
|
||||
@@ -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™, 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™, exerts a pervasive influence on the Eiffel style of software development.
|
||||
|
||||
|
||||
|
||||
|
||||
@@ -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>
|
||||
|
||||
Reference in New Issue
Block a user