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

Author:halw

Browse Source 
Date:2009-11-11T18:50:11.000000Z


git-svn-id: https://svn.eiffel.com/eiffel-org/trunk@354 abb3cda0-5349-4a8f-a601-0c33ac3a8c38
This commit is contained in:
halw
2009-11-11 18:50:11 +00:00
parent 0cafe122f9
commit 0c3a7bc03b
7 changed files with 72 additions and 3 deletions
Download Patch File Download Diff File Expand all files Collapse all files

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

@@ -20,7 +20,7 @@ Of course, you should remember from previous discussions that <code>l_x</code> m
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 members of the Eiffel standards committee have been able to produce and publish as part of the [http://www.ecma-international.org/publications/standards/Ecma-367.htm standard] 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.
What happened instead is that the members of the Eiffel standard committee have been able to produce and publish as part of the [http://www.ecma-international.org/publications/standards/Ecma-367.htm standard] 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.
@@ -176,7 +176,9 @@ Another not-so-obvious CAP is related to the use of the logical implication:
In summary, CAPs provide void-safe protection for certain types of detachable expressions.
Possibly the characteristic of CAPs which is most important to developers is whether or not a particular CAP is supported by the compiler. In other words, if the compiler can provide assurance that a certain code pattern provides void-safe protection, then the developer has that pattern available as a CAP. Likewise, even if a pattern can be shown to be a CAP, but for some reason it is not supported by the compiler, then that pattern is not available as a CAP and the compiler will not allow its use.
Possibly the characteristic of CAPs which is most important to developers is whether or not a particular CAP is supported by the compiler. In other words, from the developers viewpoint, the only opinion that matters in the argument of whether a particular pattern constitutes a CAP is that of the compiler.
If the compiler can provide assurance that a certain code pattern provides void-safe protection, then the developer has that pattern available as a CAP. Likewise, even if a pattern can be shown to be a CAP, but for some reason it is not supported by the compiler, then that pattern is not available as a CAP and the compiler will not allow its use.