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

Fixed a typo and corrected the explanation for the example with an attached formal generic type.

Browse Source 
Updated wikipage Void-safety: Background, definition, and tools.
	(Signed-off-by:alexk).

git-svn-id: https://svn.eiffel.com/eiffel-org/trunk@2341 abb3cda0-5349-4a8f-a601-0c33ac3a8c38
This commit is contained in:
eiffel-org
2021-12-20 10:13:54 +00:00
parent 93437267fd
commit d20341459e
1 changed files with 4 additions and 2 deletions
Download Patch File Download Diff File Expand all files Collapse all files

6
documentation/21.11/eiffel/Language_reference/void-safe-programming-eiffel/void-safety-background-definition-and-tools.wiki
View File

@@ -1,3 +1,5 @@
[[Property:modification_date|Mon, 20 Dec 2021 10:13:53 GMT]]
[[Property:publication_date|Mon, 20 Dec 2021 10:13:53 GMT]]
[[Property:link_title|Background and tools]]
[[Property:title|Void-safety: Background, definition, and tools]]
[[Property:weight|0]]
@@ -67,7 +69,7 @@ We know that in the context of certain code patterns, it is clear that it would
Here a check is made to ensure <code>x</code> is not void. Then as long as no assignments to <code>x</code> are made in the interim, a feature <code>f</code> can be applied to <code>x</code> with the certainty that <code>x</code> will be attached at the time ... and importantly, this can be determined at compile time. So, we say that this code pattern is a CAP for <code>x</code>.
It is important to understand that in this example (and with other CAPs), <code>x</code> is allowed to be a local variable or formal argument only. That is, <code>x</code> may not be an attribute or general expression (with one exception which we will see [[#Stable attributes|below]]). Direct access to class attribute references cannot be allowed via a CAP due to the fact that they could be set to void by a routine call in some execution path invoked by the intervening instructions or possibly even different process thread. In a later [[Void-safety: Background, definition, and tools#Types as "attached" or "detachable"|section]], we well see that this is not quite such a limitations as it may appear at this point.
It is important to understand that in this example (and with other CAPs), <code>x</code> is allowed to be a local variable or formal argument only. That is, <code>x</code> may not be an attribute or general expression (with one exception which we will see [[#Stable attributes|below]]). Direct access to class attribute references cannot be allowed via a CAP due to the fact that they could be set to void by a routine call in some execution path invoked by the intervening instructions or possibly even different process thread. In a later [[Void-safety: Background, definition, and tools#Types as "attached" or "detachable"|section]], we will see that this is not quite such a limitations as it may appear at this point.
{{note|You will find more useful information about CAPs in [[Creating a new void-safe project#More about CAPs|More about CAPs]]. Learn how certain code patterns are determined to be CAPs in [[What makes a Certified Attachment Pattern]]. }}
@@ -263,7 +265,7 @@ Constrained genericity can be used to create generic classes in which the generi
class C [G -> attached ANY]
...
</code>
then <code>x</code> in this class <code>G</code> represents an attached type. Consequently, the actual generic type in any derivation must be attached ... and feature calls on <code>x</code> are safe.
then <code>x</code> in this class has attached type <code>G</code>. Consequently, the actual generic type in any derivation must be attached ... and feature calls on <code>x</code> are safe.
==Rule for ARRAYs==