Multiple constraints

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.

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?

Proposed semantic: