Difference between revisions of "New CAT call"

Revision as of 14:00, 6 November 2006

Introduction

The ECMA standard introduces a new solution to the CAT call problem. Covariant redefinition of a formal argument is only possible to a detachable type:

class A
feature
   f (a: ANY) do end
end

class B1
inherit A redefine f end
feature
   f (a: STRING) do end   -- not valid
end

class B2
inherit A redefine f end
feature
   f (a: ?STRING) do end   -- valid
end

The most obvious observation is, that this weakens the new non-void typing mechanism, it is now possible to pass void to feature f of class B2. On the other side, ECMA-2 is not very clear about what happens when an object of type INTEGER_REF is passed to feature f of B2 (this is possible through a reference of class A). Either a is attached to the INTEGER_REF object or a is detached. The former would require, that a reference of a detachable type can be either Void or attached to an object of arbitrary type. The latter, that feature f of class B2 cannot detect CAT-calls. Neither of the two seems to be acceptable. ECMA-2 says nothing about the CAT-call problem with covariant generics. If the same approach would be taken as for covariant redeclaration, a type parameter would always be of a detachable type. To give an idea of how handy the new approach is in practice, it helps to think about what the advantage of having covariance in the language is. In languages that do not support covariant redeclaration (Java, C++, C#) this feature is simulated by making an object test whenever an argument is used. But this is exactly what the Eiffel programmer will need to do in the future. To put it in short, with the new CAT call solution Eiffel will have a much weaker support for covariance. Its advantage compared to other language will only be minimal and not justify its complexity.

Detachable type

According to the new approach a detachable type can be attached to an object of "any" type.