From aa1c9e08337d74ab2e0e3ae0fd469457bf4b3b47 Mon Sep 17 00:00:00 2001 From: jfiat Date: Tue, 15 Sep 2009 06:41:24 +0000 Subject: [PATCH] Author:halw Date:2009-09-15T01:22:19.000000Z git-svn-id: https://svn.eiffel.com/eiffel-org/trunk@299 abb3cda0-5349-4a8f-a601-0c33ac3a8c38 --- .../et-dynamic-structure-execution-model.wiki | 2 +- ...afety-background-definition-and-tools.wiki | 3 +-- ...at-makes-certified-attachment-pattern.wiki | 21 +++++++++++++++++++ 3 files changed, 23 insertions(+), 3 deletions(-) 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 4c912f46..cb167df7 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 @@ -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 x := y the target x must be an entity. More precisely it must be a '''writable''' entity. This notion excludes formal routine arguments: as noted, a routine r (arg: SOME_TYPE) may not assign to arg (reattaching it to a different object), although it can change the attached objects through calls of the form arg.procedure (...) . -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 obj.some_attribute := some_value -- This syntax is disallowed (except in the presence of an `assigner command', see below) diff --git a/documentation/current/method/void-safe-programming-eiffel/void-safety-background-definition-and-tools.wiki b/documentation/current/method/void-safe-programming-eiffel/void-safety-background-definition-and-tools.wiki index 567a690e..e5f6baeb 100644 --- a/documentation/current/method/void-safe-programming-eiffel/void-safety-background-definition-and-tools.wiki +++ b/documentation/current/method/void-safe-programming-eiffel/void-safety-background-definition-and-tools.wiki @@ -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 make procedure would not do this. Creation of an ARRAY in which the actual generic parameter is attached must be done using the make_filled creation procedure. - create my_array.make_filled (1, 100, "") + create my_array.make_filled ("", 1, 100) The third argument is an object of the actual generic type, in this case an empty STRING. Every entry in the newly created ARRAY will be initialized to reference this object. diff --git a/documentation/current/method/void-safe-programming-eiffel/what-makes-certified-attachment-pattern.wiki b/documentation/current/method/void-safe-programming-eiffel/what-makes-certified-attachment-pattern.wiki index e267cdf8..c73dc10c 100644 --- a/documentation/current/method/void-safe-programming-eiffel/what-makes-certified-attachment-pattern.wiki +++ b/documentation/current/method/void-safe-programming-eiffel/what-makes-certified-attachment-pattern.wiki @@ -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 exp of a detachable type that ensures that exp will never have a void run-time value within the covered scope. + +A simple example is the familiar test for void reference: + + if x /= Void then + x.do_something + end + +We know that after the explicit check to make sure x is not Void, that the feature application x.do_something is void-safe. +Of course, you should remember from previous discussions that x 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. + + +