Difference between revisions of "New CAT call"
m (→Detachable type) |
m (→Introduction) |
||
Line 28: | Line 28: | ||
</code> | </code> | ||
|} | |} | ||
− | + | ||
+ | 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). There are two possibilities: | ||
+ | * a is attached to an object of dynamic type INTEGER_REF. | ||
+ | * 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. | This wiki discusses some of concerns related to this solution. | ||
==Detachable type== | ==Detachable type== | ||
According to the new approach a detachable type can be attached to an object of "any" type. | According to the new approach a detachable type can be attached to an object of "any" type. |
Revision as of 15:02, 27 October 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 |
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). There are two possibilities:
- a is attached to an object of dynamic type INTEGER_REF.
- 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.