Difference between revisions of "Multiple constraints"
| Line 1: | Line 1: | ||
[[Category:ECMA]] | [[Category:ECMA]] | ||
==Description== | ==Description== | ||
| + | This article discusses issues which arise in conjunction with multiple constrained type parameters. | ||
====New multiple constraints for generic parameters==== | ====New multiple constraints for generic parameters==== | ||
| Line 7: | Line 8: | ||
{|border="0" cellpadding="2" cellspacing="0" align="center" | {|border="0" cellpadding="2" cellspacing="0" align="center" | ||
|-valign="top" -halign="center" | |-valign="top" -halign="center" | ||
| + | |[[Image:Class_diagram_for_multiple_constraints_explanation.png|173px]] | ||
| | | | ||
| + | | | ||
| + | Example: | ||
<code>[eiffel,N] | <code>[eiffel,N] | ||
class GENERIC_CLASS [G -> {B, C }] | class GENERIC_CLASS [G -> {B, C }] | ||
feature | feature | ||
| + | |||
f: G | f: G | ||
| + | t (g: G) do end | ||
example is | example is | ||
-- issue | -- issue | ||
| − | do | + | do |
| − | + | f.a -- Line 1: feature call | |
| − | + | ||
| + | |||
end | end | ||
| Line 27: | Line 34: | ||
The semantic given to the code above is, that an actual parameter passed for G must be conform to both classes: B and C. | The semantic given to the code above is, that an actual parameter passed for G must be conform to both classes: B and C. | ||
| − | The standard defines in section 8.12.23 what the basic type of such a multiple constraint formal generic is. | + | ====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. The [http://eiffelsoftware.origo.ethz.ch/index.php/Transposition#The_new_dynamic_binding_semantics new semantics of dynamic binding] require an existing basic type which is then used as the static type 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? | So the question the ECMA Standard does not answer is: What is the static type of a formal generic which has multiple constraints? | ||
| + | |||
| + | ====Proposed semantic: ==== | ||
Revision as of 14:20, 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 generic 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
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. The new semantics of dynamic binding require an existing basic type which is then used as the static type 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?
