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

Author:manus

Browse Source 
Date:2009-08-25T23:29:10.000000Z


git-svn-id: https://svn.eiffel.com/eiffel-org/trunk@288 abb3cda0-5349-4a8f-a601-0c33ac3a8c38
This commit is contained in:
manus
2009-08-25 23:29:10 +00:00
parent 179b63f74c
commit ab128547cc
1 changed files with 3 additions and 1 deletions
Download Patch File Download Diff File Expand all files Collapse all files

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

@@ -200,7 +200,7 @@ where <code>x</code> is the formal argument for <code>r</code>, then if x is of
===Stable attributes===
Stable attributes are really stable ''detachable'' attributes, as adding the concept of stability is meaningful only for detachable attributes. Declaring a detachable attribute as stable, means that it behaves like a detachable attribute except that its assignment rules mimic those of attached attributes. In other words, a stable attribute can never be the target of an assignment in which the source is <code>Void</code> or a detachable type.
Stable attributes are really stable ''detachable'' attributes, as adding the concept of stability is meaningful only for detachable attributes. Declaring a detachable attribute as stable, means that it behaves like a detachable attribute except that its assignment rules mimic those of attached attributes. In other words, a stable attribute does not need to be attached upon creation like attached attributes do. But like attached attributes, stable attributes can never be the target of an assignment in which the source is <code>Void</code> or a detachable type.
<code>
my_test: detachable TEST
note
@@ -211,6 +211,8 @@ Stable attributes are really stable ''detachable'' attributes, as adding the con
This means that even though stable attributes do not need to be initialized like attached attributes, once they are attached to an object, they can never be void again.
Stable attributes are also interesting in that they are the only exception to the rule given in the [[Void-safety: Background, definition, and tools#Certified Attachment Patterns (CAPs)|CAPs section]] above that said that access to attributes cannot be protected by a CAP. A stable attribute can be used under the protection of a CAP. This is because once a stable attribute has an object attached, it can never again be set to <code>Void</code>. So there's no worry about having the attribute's state going from attached to non-attached because of the actions of other routines or threads.
===Rule for generic parameters===
Generic classes provide another question. A generic class like