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-16T23:27:03.000000Z


git-svn-id: https://svn.eiffel.com/eiffel-org/trunk@301 abb3cda0-5349-4a8f-a601-0c33ac3a8c38
This commit is contained in:
halw
2009-09-16 23:27:03 +00:00
parent 0634355ebc
commit edd0fe209f
2 changed files with 8 additions and 5 deletions
Download Patch File Download Diff File Expand all files Collapse all files

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

@@ -94,7 +94,7 @@ By using the '''attached syntax''', we can perform an '''object test''' on a var
In the example above, <code>x</code> is tested to make certain that it is attached. If so, the new local <code>l_x</code> becomes attached to the same object as <code>x</code>. And so the object can be used safely even if <code>x</code> 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.

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

@@ -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 <code>exp</code> whose type is detachable is an occurrence of <code>exp</code> in one of the following contexts: ''
#'' <code>exp</code> is an Object-Test Local and the occurrence is in its scope. ''
#'' <code>exp</code> is a read-only entity and the occurrence is in the scope of a void test involving <code>exp</code>.''
'''''A Certified Attachment Pattern (or CAP) for an expression <code>exp</code> whose type is detachable is an occurrence of <code>exp</code> in one of the following contexts: '''''
'''''1. <code>exp</code> is an Object-Test Local and the occurrence is in its scope. '''''
'''''2. <code>exp</code> is a read-only entity and the occurrence is in the scope of a void test involving <code>exp</code>.'''''
----
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.