From edd0fe209fd54812439d00bc35554a980ba04547 Mon Sep 17 00:00:00 2001 From: halw Date: Wed, 16 Sep 2009 23:27:03 +0000 Subject: [PATCH] Author:halw Date:2009-09-16T23:27:03.000000Z git-svn-id: https://svn.eiffel.com/eiffel-org/trunk@301 abb3cda0-5349-4a8f-a601-0c33ac3a8c38 --- .../void-safety-background-definition-and-tools.wiki | 2 +- .../what-makes-certified-attachment-pattern.wiki | 11 +++++++---- 2 files changed, 8 insertions(+), 5 deletions(-) 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 4be40f8f..8856df42 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 @@ -94,7 +94,7 @@ By using the '''attached syntax''', we can perform an '''object test''' on a var In the example above, x is tested to make certain that it is attached. If so, the new local l_x becomes attached to the same object as x. And so the object can be used safely even if x is a class attribute. So, the attached syntax, is really another CAP, because it provides a clearly verifiable place for the application of features to targets that are guaranteed not to be void. -{{note|The attached syntax has other syntax variations as well as other uses. These will be discussed later. }} +{{note|The attached syntax has other syntax variations as well as other uses. These will be discussed [[Creating a new void-safe project#More about the attached syntax|later]]. }} 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. 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 41e900af..62a0ecdf 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 @@ -29,12 +29,15 @@ The definition in the standard document is not easily readable by most developer The Eiffel standard (2nd edition, June 2006) defines a CAP as follows: ---- -''A Certified Attachment Pattern (or CAP) for an expression exp whose type is detachable is an occurrence of exp in one of the following contexts: '' -#'' exp is an Object-Test Local and the occurrence is in its scope. '' -#'' exp is a read-only entity and the occurrence is in the scope of a void test involving exp.'' +'''''A Certified Attachment Pattern (or CAP) for an expression exp whose type is detachable is an occurrence of exp in one of the following contexts: ''''' + + +'''''1. exp is an Object-Test Local and the occurrence is in its scope. ''''' + +'''''2. exp is a read-only entity and the occurrence is in the scope of a void test involving exp.''''' ---- -The terminology used in the definition is precise. For example, terms like "read-only" entity and "scope of a void test" have specific meanings that are supported by their own definitions in the standard. +The terminology used in the definition is precise. For example, terms like "read-only entity" and "scope of a void test" have specific meanings that are supported by their own definitions in the standard. Here we will consider the CAP definition only, but our discussion will be supported by the ancillary definitions. Of course, the [http://www.ecma-international.org/publications/standards/Ecma-367.htm standard document] is available for download if you need to review the specific details.