Difference between revisions of "Catcall Test Proposal"
(→New conformance rules) |
Peter gummer (Talk | contribs) m |
||
| (4 intermediate revisions by one other user not shown) | |||
| Line 1: | Line 1: | ||
[[Category:ECMA]] | [[Category:ECMA]] | ||
| − | This article | + | This article describes an implementation made by Eiffel Software in October 2007 for a solution of the CATCALL issue. It is a variation on an already discussed solution. |
== Syntax changes == | == Syntax changes == | ||
A Type declaration can be preceded by the keyword <e>frozen</e>, that is to say: | A Type declaration can be preceded by the keyword <e>frozen</e>, that is to say: | ||
| − | |||
<e> | <e> | ||
a: frozen A</e> | a: frozen A</e> | ||
An actual generic parameter can be preceded by the keyword <e>variant</e>, that is to say: | An actual generic parameter can be preceded by the keyword <e>variant</e>, that is to say: | ||
| − | |||
<e> | <e> | ||
a: LIST [variant A]</e> | a: LIST [variant A]</e> | ||
| Line 16: | Line 14: | ||
When the actual generic parameters are preceded by <e>variant</e> then the existing conformance rules apply, otherwise it has to be the same type. | When the actual generic parameters are preceded by <e>variant</e> then the existing conformance rules apply, otherwise it has to be the same type. | ||
| − | {{Note| This new rule although more restrictive than what we are used to seems to be the right way to go to avoid breaking too much existing code. An experiment done on the Eiffel batch compiler shows that with existing rules we would get about 40,000 catcall violations. With the new rules, we only get | + | {{Note| This new rule although more restrictive than what we are used to seems to be the right way to go to avoid breaking too much existing code. An experiment done on the Eiffel batch compiler shows that with existing rules we would get about 40,000 catcall violations. With the new rules, we only get 2,000 conformance errors.}} |
== New validity rules == | == New validity rules == | ||
| − | # The target of a call involving a covariantly redefined routine should either be marked <e>frozen</e> or else the call has to be valid for all descendant types. | + | # The target of a call involving a covariantly redefined routine should either be marked <e>frozen</e> or else the call has to be valid for all descendant types of the target type. |
| − | # If the formal arguments of a call involves a formal generic parameter, the corresponding actual should not be marked <e>variant</e>. | + | # If one of the formal arguments of a call involves a formal generic parameter, the corresponding actual should not be marked <e>variant</e>. |
| − | == Implementation | + | == Implementation issues== |
| − | The tricky part in the above is the | + | The tricky part in the above is the check for the validity of a covariant call for all the descendant types of the target. The issue is when a descendant type is generic and the new formal generic parameter has no corresponding type in the ancestor. For example: |
<e> | <e> | ||
class A | class A | ||
| Line 50: | Line 48: | ||
end | end | ||
</e> | </e> | ||
| − | In our case, we assume the descendant type to be instantiated with its constraint, in the above case <e>B [ANY]</e>. | + | In our case, we assume the descendant type to be instantiated with its constraint, in the above case <e>B [ANY]</e>. This only works with a single constraint; in the case of multiple constraints, our compiler will simply report a potential catcall due to a compiler limitation. |
Latest revision as of 13:36, 6 November 2007
This article describes an implementation made by Eiffel Software in October 2007 for a solution of the CATCALL issue. It is a variation on an already discussed solution.
Syntax changes
A Type declaration can be preceded by the keyword frozen, that is to say:
a: frozen A
An actual generic parameter can be preceded by the keyword variant, that is to say:
a: LIST [variant A]
New conformance rules
When the actual generic parameters are preceded by variant then the existing conformance rules apply, otherwise it has to be the same type.
Note: This new rule although more restrictive than what we are used to seems to be the right way to go to avoid breaking too much existing code. An experiment done on the Eiffel batch compiler shows that with existing rules we would get about 40,000 catcall violations. With the new rules, we only get 2,000 conformance errors.
New validity rules
- The target of a call involving a covariantly redefined routine should either be marked
frozenor else the call has to be valid for all descendant types of the target type. - If one of the formal arguments of a call involves a formal generic parameter, the corresponding actual should not be marked
variant.
Implementation issues
The tricky part in the above is the check for the validity of a covariant call for all the descendant types of the target. The issue is when a descendant type is generic and the new formal generic parameter has no corresponding type in the ancestor. For example:
class A f (a: ANY) do end end class B [G] inherit A redefine f end feature f (a: STRING) do end end class TEST feature make is local a: A do a.f ("My String") end end end
In our case, we assume the descendant type to be instantiated with its constraint, in the above case B [ANY]. This only works with a single constraint; in the case of multiple constraints, our compiler will simply report a potential catcall due to a compiler limitation.
