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

Clarification added to rule for formal generic parameters.

Browse Source 
Author:halw
Date:2010-08-01T15:42:36.000000Z


git-svn-id: https://svn.eiffel.com/eiffel-org/trunk@646 abb3cda0-5349-4a8f-a601-0c33ac3a8c38
This commit is contained in:
halw
2010-08-01 15:42:36 +00:00
parent c8e36331a8
commit 0ce37429b7
1 changed files with 9 additions and 3 deletions
Download Patch File Download Diff File Expand all files Collapse all files

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

@@ -249,9 +249,15 @@ What do we know about the void-safety of <code>x</code> ?
In the case of the <code>INTEGER</code> derivation above, we know <code>x</code> is safe because <code>INTEGER</code> is an expanded type. But often types like <code>EMPLOYEE</code> will be reference types which could be void at run time. In the case of the <code>INTEGER</code> derivation above, we know <code>x</code> is safe because <code>INTEGER</code> is an expanded type. But often types like <code>EMPLOYEE</code> will be reference types which could be void at run time.
So for a class like <code>C [G]</code> containing a declaration <code>x: G</code> : '''For a class like <code>C [G]</code>, <code>G</code> is considered detachable'''. As a result, because of the [[Void-safety: Background, definition, and tools#Rule for conformance|rule for conformance]], any class will work for an actual generic parameter. That means that both of the following are valid generic derivations:
* <code>G</code> is considered detachable and any class will work for an actual generic parameter
* Application of features to <code>x</code> must include verification of attachment (CAPs, attached syntax, etc) <code>
my_detachable_string_derivation: C [detachable STRING]
my_attached_string_derivation: C [attached STRING]
</code>
If <code>C</code> contains a declaration <code>x: G</code>, the application of features to <code>x</code> must include verification of attachment (CAPs, attached syntax, etc).
Constrained genericity can be used to create generic classes in which the generic parameter represents an attached type. If class <code>C</code> had been defined as: Constrained genericity can be used to create generic classes in which the generic parameter represents an attached type. If class <code>C</code> had been defined as:
<code> <code>