mirror of
https://github.com/EiffelSoftware/eiffel-org.git
synced 2025-12-08 15:52:26 +01:00
Clarification added to rule for formal generic parameters.
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:
@@ -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.
|
||||
|
||||
So for a class like <code>C [G]</code> containing a declaration <code>x: G</code> :
|
||||
* <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)
|
||||
'''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>
|
||||
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:
|
||||
<code>
|
||||
|
||||
Reference in New Issue
Block a user