New CAT call

Revision as of 14:38, 6 November 2006 by Konradm (Talk | contribs)

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.

Both solutions have their own drawbacks and will be discussed in the next two sections. The rest of the wiki covers problems that are not related to this interpretation.

CAT call results in attached argument

This has the consequence,

CAT call results in detached argument

Is is not possible for the called feature to detect, whether there was a CAT call or the caller just passed a Void reference. CAT calls would thus not be detected at both compile- and run-time.

CAT call results in an argument attached argument

  • as is detached.

Will a be attached to void or will it be attached to the INTEGER_REF This wiki discusses some of concerns related to this solution.

Detachable type

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