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

Author:halw

Browse Source 
Date:2009-09-15T01:22:19.000000Z


git-svn-id: https://svn.eiffel.com/eiffel-org/trunk@299 abb3cda0-5349-4a8f-a601-0c33ac3a8c38
This commit is contained in:
jfiat
2009-09-15 06:41:24 +00:00
parent 3e7adb8214
commit aa1c9e0833
3 changed files with 23 additions and 3 deletions
Download Patch File Download Diff File Expand all files Collapse all files

2
documentation/current/method/eiffel-tutorial-et/et-dynamic-structure-execution-model.wiki
View File

@@ -603,7 +603,7 @@ The only exception to the last rule is termination of the original root procedur
The description of assignments stated that in <code>x := y</code> the target <code>x</code> must be an entity. More precisely it must be a '''writable''' entity. This notion excludes formal routine arguments: as noted, a routine <code>r (arg: SOME_TYPE)</code> may not assign to <code>arg</code> (reattaching it to a different object), although it can change the attached objects through calls of the form <code>arg.procedure (...)</code> .
Restricting the targets of assignments to entities precludes assignments of the form
Allowing only entities to be the targets of assignments precludes assignments of the form
<code>
obj.some_attribute := some_value
-- This syntax is disallowed (except in the presence of an `assigner command', see below)

3
documentation/current/method/void-safe-programming-eiffel/void-safety-background-definition-and-tools.wiki
View File

@@ -1,7 +1,6 @@
[[Property:title|Void-safety: Background, definition, and tools]]
[[Property:weight|0]]
[[Property:uuid|689f62b2-5675-5ab6-cd47-d891cf3d484d]]
=Background=
The primary focus of Eiffel is on software quality. Void-safety, like static typing, is another facility for improving software quality. Void-safe software is protected from run time errors caused by calls to void references, and therefore will be more reliable than software in which calls to void targets can occur. The analogy to static typing is a useful one. In fact, void-safe capability could be seen as an extension to the type system, or a step beyond static typing, because the mechanism for ensuring void-safety is integrated into the type system.
@@ -262,7 +261,7 @@ During creation, an area to store the appropriate number of entries is also crea
In the case of an actual generic parameter of an attached reference type, all the elements must be attached to instances of type during the creation of the ARRAY. The <code>make</code> procedure would not do this. Creation of an <code>ARRAY</code> in which the actual generic parameter is attached must be done using the <code>make_filled</code> creation procedure.
<code>
create my_array.make_filled (1, 100, "")
create my_array.make_filled ("", 1, 100)
</code>
The third argument is an object of the actual generic type, in this case an empty <code>STRING</code>. Every entry in the newly created <code>ARRAY</code> will be initialized to reference this object.

21
documentation/current/method/void-safe-programming-eiffel/what-makes-certified-attachment-pattern.wiki
View File

@@ -5,6 +5,27 @@
==A little background on CAPs==
Certified Attachment Patterns (CAPs) were described in the section on [[Void-safety: Background, definition, and tools#Certified attachment patterns (CAPs)|void-safety tools]]. To review, a CAP is a code pattern for a certain expression, say <code>exp</code> of a detachable type that ensures that <code>exp</code> will never have a void run-time value within the covered scope.
A simple example is the familiar test for void reference:
<code>
if x /= Void then
x.do_something
end
</code>
We know that after the explicit check to make sure <code>x</code> is not <code>Void</code>, that the feature application <code>x.do_something</code> is void-safe.
Of course, you should remember from previous discussions that <code>x</code> must be a local variable, a formal argument, or a [[Void-safety: Background, definition, and tools#Stable attributes|stable attribute]].
When void-safety was first envisioned for Eiffel, it was intended that individual CAPs would be proven or certified and documented. This would produce a "catalog" of CAPs.
What happened instead is that the standard committee was able to produce a definition of the nature of a CAP from which a determination can be made as to whether a particular code pattern is or is not a CAP.
The definition in the standard document is not easily readable by most developers. So, in this documentation, you will see various examples of CAPs and the rationale behind them.