Multiple constraints

Revision as of 15:20, 30 October 2006 by Seilerm (Talk | contribs)

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.

Class diagram for multiple constraints explanation.png

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?

Proposed semantic: