This solution allows covariantly redefined features only to use detachable types. Through this mechanism, an object test is necessary before an argument can be used. This forces the programmer to test arguments for validity.
This is specified in the ECMA Eiffel standard 2nd edition of June 2006.
No new syntax is necessary.
In this solution, it is only allowed to covariantly redefine arguments to detachable types. This ensures that an object test is done before the use of an argument. If now a catcall happens, the object test will fail. Since the argument is of detachable type, the programmer has to handle the case where Void is passed anyway and this also handles the catcall.
See the introduction to examples for information about the classes used.
Cats and dogs
The definition of the CAT class changes as follows:
class CAT inherit ANIMAL redefine eat end feature eat (food: detachable CAT_FOOD) do if attached food as cat_food then -- Use `cat_food' else -- either Void or an argument of type FOOD passed end end end
Weak covariance support
With the current conformance of generics, different generic derivations can be seen as if they covariantly redefined the features with formal generic parameters. For example feature
put from the class
LIST if you look at the signature of
LIST [ANY] compared to
LIST [STRING]. As with anchored types as parameters, you would also have to specify that all formal generic parameters need to be detached. This would mean that all classes which use generic parameters always have to use object tests to use the generic parameters, and Void-safety cannot be expressed on the type system level which would remove the main benefit of attached types in the context of generics.
The type rule specified by ECMA (VTCT, 8.11.8) defines that an expanded type cannot have an attachment mark since Void is not a valid value for it. Given that covariant feature redeclaration, especially anchored types for arguments, can only occur with detached types, this means that arguments cannot be covariantly redefined into expanded types.
The base classes like
INTEGER which currently inherit from
NUMERIC which only defines its arguments as
like Current would be invalid in their current form. Also if formal generic parameters need to be detached as explained above, generic derivations would not be allowed for expanded types if the formal generic occurs as a parameter of a feature. Especially
LIST [INTEGER] would not be possible.
The problems arise partially due to the fact that two concepts are mixed:
- Attachable/detachable types: A type
? Tcan be attached to an object of type T or not attached at all (i.e. Void)
- Catcall arguments: In a catcall, the type of the argument can either be the expected type or the type of an ancestor version of the feature.
By using detachable types to solve catcalls, the notion of a detachable type is expanded to be able to hold types of all ancestors as well.
In addition to this, the problems with generics and expanded types show that this solution does severely limit the usefulness of covariance.