Difference between revisions of "New CAT call"
m (→Introduction) |
m (→Introduction) |
||
Line 29: | Line 29: | ||
|} | |} | ||
− | ECMA-2 is not very clear about what happens when an INTEGER_REF is passed to feature f of B2 (this is possible through a reference of class A). Either a is attached to | + | 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. 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 detached argument==== | ||
+ | |||
+ | ====CAT call results in an argument attached argument==== | ||
+ | |||
* as is detached. | * as is detached. |
Revision as of 15:11, 27 October 2006
Contents
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 |
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. 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 detached argument
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.