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

Author:halw

Browse Source 
Date:2009-10-22T22:06:48.000000Z


git-svn-id: https://svn.eiffel.com/eiffel-org/trunk@336 abb3cda0-5349-4a8f-a601-0c33ac3a8c38
This commit is contained in:
halw
2009-10-22 22:06:48 +00:00
parent 312bca43d7
commit 9502f2ac67
1 changed files with 32 additions and 4 deletions
Download Patch File Download Diff File Expand all files Collapse all files

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

@@ -39,23 +39,51 @@ The Eiffel standard (2nd edition, June 2006) defines a CAP as follows:
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 discussion here will be less formal (and less precise) than that in the standard, and is intended to be a practical guide. Of course, the [http://www.ecma-international.org/publications/standards/Ecma-367.htm standard document] is available for download if you wish to follow the specifics.
Still, the standard does contain informative text that gives us a guideline that a CAP is a scheme to ensure that a particular expression of a detachable type will never have void run-time value in the scope covered by the CAP.
The discussion here will follow that guideline, and, as such, will be less formal (and consequently less precise) than that in the standard, and is intended to be a practical guide. Of course, the [http://www.ecma-international.org/publications/standards/Ecma-367.htm standard document] is available for download if you wish to investigate the specifics.
==CAP-able expressions==
In the first context, the definition states that the expression <code>exp</code> can be an '''Object-Test Local'''. An Object-Test Local is the identifier specified for a fresh local entity in an '''object test'''. Remember, object tests are coded using the '''attached syntax'''.
In the first context in the definition above, the expression <code>exp</code> can be an '''Object-Test Local'''. An Object-Test Local is the identifier specified for a fresh local entity in an '''object test'''. Remember, object tests are coded using the [[Void-safety: Background, definition, and tools#The attached syntax (object test)|attached syntax]].
<code>
attached x as l_x
</code>
In the object test expression above, the identifier <code>l_x</code> is an Object-Test Local.
In the object test expression above, the identifier '''<code>l_x</code>''' is an Object-Test Local.
In the second context, the expression can be a read-only entity. Read-only entities are:
In the second context, the expression can be a '''read-only entity'''. Read-only entities are:
# Constant attributes
# Formal arguments
# Object-Test Locals
# <code>Current</code>
Additionally, the Eiffel Software compiler allows for [[Void-safety: Background, definition, and tools#Stable attributes|stable attributes]] and local variables to be protected by a CAP.
Stable attributes are the only class attributes which are CAP-able. This is because stable attributes, once attached at run-time, can never have a void value again.
Local variables can be used in a CAP as long as they are not the target of an assignment whose source is <code>Void</code> or some expression which could possibly be void.
So, for a local variable <code>l_string</code>, the following is valid:
<code>
local
l_string: detachable STRING
do
if l_string /= Void then
l_string.append ("xyz") -- Valid
...
</code>
But, if <code>l_string</code> had been a target of an assignment in which the source could possibly have been void, then it could no longer be guaranteed that <code>l_string</code> is non-void. So, assuming that <code>my_detachable_string</code> is an attribute declared as type <code>detachable STRING</code>, the code in this example would be invalid:
<code>
local
l_string: detachable STRING
do
if l_string /= Void then
l_string := my_detachable_string
l_string.append ("xyz") -- Invalid: my_detachable_string could be void
...
</code>