Difference between revisions of "Multiple constraints"
| Line 4: | Line 4: | ||
====New multiple constraints for generic parameters==== | ====New multiple constraints for generic parameters==== | ||
| − | With the new [http://www.ecma-international.org/publications/standards/Ecma-367.htm ECMA standard] for Eiffel multiple constraints for | + | With the new [http://www.ecma-international.org/publications/standards/Ecma-367.htm ECMA standard] for Eiffel multiple constraints for type parameters were introduced. |
{|border="0" cellpadding="2" cellspacing="0" align="center" | {|border="0" cellpadding="2" cellspacing="0" align="center" | ||
|-valign="top" -halign="center" | |-valign="top" -halign="center" | ||
| − | |||
| | | | ||
| | | | ||
| Line 35: | Line 34: | ||
====Explanation of the issue==== | ====Explanation of the issue==== | ||
| − | The standard defines in section 8.12.23 what the basic type of such a multiple constraint formal generic is. It is fictive class (denoted as a dashed "{B,C}" class in the diagramm) which inherits from all constraint classes and to which a possible renaming is applied. | + | Consider the above example together with the following inheritance hierarchy: |
| + | |||
| + | [[Image:Class_diagram_for_multiple_constraints_explanation.png|173px]] | ||
| + | |||
| + | The standard defines in section 8.12.23 what the basic type of such a multiple constraint formal generic is. It is a fictive class (denoted as a dashed "{B,C}" class in the diagramm) which inherits from all constraint classes and to which a possible renaming is applied. Dynamic binding requires a clear notion of what the static type of a target (here f) is. One normally would take the basic type of the target as the static type. which is then used for the call. | ||
If B and/or C redefine the feature ''f'' the problem is resolved by renaming and one can chose from which branch the feature is called. If until the level of ''{B,C}'' no redefinition of feature ''f'' has occured the decision which static type to use is getting more complicate: The feature ''f'' could for exmaple be redefined in ''B' ''and/or ''C' ''. In taht case ''X'' would then select one of them. This yields is an ambiguity which the current ECMA Standard (version 2) does not resolve. | If B and/or C redefine the feature ''f'' the problem is resolved by renaming and one can chose from which branch the feature is called. If until the level of ''{B,C}'' no redefinition of feature ''f'' has occured the decision which static type to use is getting more complicate: The feature ''f'' could for exmaple be redefined in ''B' ''and/or ''C' ''. In taht case ''X'' would then select one of them. This yields is an ambiguity which the current ECMA Standard (version 2) does not resolve. | ||
Revision as of 15:27, 30 October 2006
Contents
Description
This article discusses issues which arise in conjunction with multiple constrained type parameters.
New multiple constraints for generic parameters
With the new ECMA standard for Eiffel multiple constraints for type parameters were introduced.
|
Example: class GENERIC_CLASS [G -> {B, C }] feature f: G t (g: G) do end example is -- issue do f.a -- Line 1: feature call end end |
The semantic given to the code above is, that an actual parameter passed for G must be conform to both classes: B and C.
Explanation of the issue
Consider the above example together with the following inheritance hierarchy:
The standard defines in section 8.12.23 what the basic type of such a multiple constraint formal generic is. It is a fictive class (denoted as a dashed "{B,C}" class in the diagramm) which inherits from all constraint classes and to which a possible renaming is applied. Dynamic binding requires a clear notion of what the static type of a target (here f) is. One normally would take the basic type of the target as the static type. which is then used for the call.
If B and/or C redefine the feature f the problem is resolved by renaming and one can chose from which branch the feature is called. If until the level of {B,C} no redefinition of feature f has occured the decision which static type to use is getting more complicate: The feature f could for exmaple be redefined in B' and/or C' . In taht case X would then select one of them. This yields is an ambiguity which the current ECMA Standard (version 2) does not resolve.
The definition of this virtual type {B,C} can only be used to clearly define the set of available features to instances of type G. It can not be used to define the semantic of a qualified feature call (like f.a).
So the question the ECMA Standard does not answer is: What is the static type of a formal generic which has multiple constraints?
