Difference between revisions of "Multiple constraints"
| Line 2: | Line 2: | ||
==Description== | ==Description== | ||
This article discusses issues which arise in conjunction with multiple constrained type parameters. | This article discusses issues which arise in conjunction with multiple constrained type parameters. | ||
| − | + | ==New multiple constraints for generic type parameters== | |
With the new [http://www.ecma-international.org/publications/standards/Ecma-367.htm ECMA standard] for Eiffel multiple constraints for type parameters were introduced. | With the new [http://www.ecma-international.org/publications/standards/Ecma-367.htm ECMA standard] for Eiffel multiple constraints for type parameters were introduced. | ||
| Line 42: | Line 42: | ||
</code> | </code> | ||
|} | |} | ||
| − | Let's first have a look at the qualified feature call ''f.a'' of the example feature. The standard defines in section ''8.12.23'' what the base type of such a multiple constrained type parameter is. It is a fictive class (denoted as a dashed class ''FICT'' 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. | + | Let's first have a look at the qualified feature call ''f.a'' of the example feature. The standard defines in section ''8.12.23'' what the base type of such a multiple constrained type parameter is. It is a fictive class (denoted as a dashed class ''FICT'' 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. To obtain the correct feature, one needs the static and dynamic type of the target at runtime. Normally the base type of the target is taken as the static type. But we cannot take this fictive base type as our static type, because, as can be seen in the diagram, he is outside of the conformance paths to X and therefore not usable with the current definition of dynamic binding in section ''8.16.11''. |
If B and/or C redefine the feature ''f'' the problem is resolved by renaming and one can chose for which conformance path 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 complicated: The feature ''f'' could for exmaple be redefined in ''B2'' and/or ''C2''. | If B and/or C redefine the feature ''f'' the problem is resolved by renaming and one can chose for which conformance path 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 complicated: The feature ''f'' could for exmaple be redefined in ''B2'' and/or ''C2''. | ||
| − | In that case ''X'' would then have to select one of them. This yields | + | In that case ''X'' would then have to select one of them. This yields somehow in an ambiguity which the current ECMA Standard (version 2) does not resolve because no obvious proper definition for the static type is given in this case. |
The definition of this fictitious type ''FICT'' 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). | The definition of this fictitious type ''FICT'' 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). | ||
| Line 51: | Line 51: | ||
====Proposed semantic: ==== | ====Proposed semantic: ==== | ||
| − | One possible solution is the following: If we have a | + | One possible solution is the following: If we have a multi-constraint generic type parameter and a qualified feature call on a target of that type, we define the static type to be the type of the class which introduced the current version of the called feature body. This must be a common ancestor of the constraining classes which contain the feature ''f'' (in our case ''B'' and ''C''). |
In our example we would set the static type of ''f'' to ''A'' and then execute the qualified feature call. | In our example we would set the static type of ''f'' to ''A'' and then execute the qualified feature call. | ||
This is somehow reasonable because if there would not be any children, we would execute the feature ''f'' defined in ''A''. If we set the static type to A we ensure that whatever occurs to ''f'' we will always execute the feature which the programmer selects to be the right feature for static type A. | This is somehow reasonable because if there would not be any children, we would execute the feature ''f'' defined in ''A''. If we set the static type to A we ensure that whatever occurs to ''f'' we will always execute the feature which the programmer selects to be the right feature for static type A. | ||
| + | |||
| + | ====Possible formal treatment==== | ||
| + | |||
| + | To ensure a proper definition in the standard, one could introducte the notion of a ''type set''. Based on those ''type sets'' one would have to formulate conformance rules, which ensure a consistent handling of the multi-constraint generic types in the first place and could maybe used later in other cases too. | ||
| + | |||
| + | A short sketch of the basic idea is the following: | ||
| + | |||
| + | Instead of introducing a fictive new type we take the set of constraint classes directly and name it ''type set of G'': | ||
| + | |||
| + | The ''type set'' of G would then simply be ''{B,C}''. | ||
| + | |||
| + | The ''type set'' of INTEGER would be {INTEGER}. | ||
| + | |||
| + | A type set A would then conform to a type set B if for every element b in B there is at least one element a in A which conforms to b. | ||
| + | <todo: formal notation> | ||
| + | |||
| + | So most of it is pretty much straightforward and chances are that it helps to make the standard more consistent. | ||
Revision as of 08:12, 31 October 2006
Contents
Description
This article discusses issues which arise in conjunction with multiple constrained type parameters.
New multiple constraints for generic type parameters
With the new ECMA standard for Eiffel multiple constraints for type parameters were introduced.
|
Example: class C [G -> {A, B }] end |
Class C expects a type parameter that conforms to B and C.
Explanation of the issue
Consider this example inheritance hierarchy together with the following code:
|
Example: class GENERIC_CLASS [G -> {B, C}] feature f: G example is do f.a -- qualified feature call end end |
Let's first have a look at the qualified feature call f.a of the example feature. The standard defines in section 8.12.23 what the base type of such a multiple constrained type parameter is. It is a fictive class (denoted as a dashed class FICT 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. To obtain the correct feature, one needs the static and dynamic type of the target at runtime. Normally the base type of the target is taken as the static type. But we cannot take this fictive base type as our static type, because, as can be seen in the diagram, he is outside of the conformance paths to X and therefore not usable with the current definition of dynamic binding in section 8.16.11.
If B and/or C redefine the feature f the problem is resolved by renaming and one can chose for which conformance path 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 complicated: The feature f could for exmaple be redefined in B2 and/or C2. In that case X would then have to select one of them. This yields somehow in an ambiguity which the current ECMA Standard (version 2) does not resolve because no obvious proper definition for the static type is given in this case.
The definition of this fictitious type FICT 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).
Proposed semantic:
One possible solution is the following: If we have a multi-constraint generic type parameter and a qualified feature call on a target of that type, we define the static type to be the type of the class which introduced the current version of the called feature body. This must be a common ancestor of the constraining classes which contain the feature f (in our case B and C).
In our example we would set the static type of f to A and then execute the qualified feature call.
This is somehow reasonable because if there would not be any children, we would execute the feature f defined in A. If we set the static type to A we ensure that whatever occurs to f we will always execute the feature which the programmer selects to be the right feature for static type A.
Possible formal treatment
To ensure a proper definition in the standard, one could introducte the notion of a type set. Based on those type sets one would have to formulate conformance rules, which ensure a consistent handling of the multi-constraint generic types in the first place and could maybe used later in other cases too.
A short sketch of the basic idea is the following:
Instead of introducing a fictive new type we take the set of constraint classes directly and name it type set of G:
The type set of G would then simply be {B,C}.
The type set of INTEGER would be {INTEGER}.
A type set A would then conform to a type set B if for every element b in B there is at least one element a in A which conforms to b. <todo: formal notation>
So most of it is pretty much straightforward and chances are that it helps to make the standard more consistent.
