Difference between revisions of "New CAT call"

m
m (syntax and style update)
 
(16 intermediate revisions by 2 users not shown)
Line 1: Line 1:
 
[[Category:ECMA]]
 
[[Category:ECMA]]
====Introduction====
+
Author: Matthias Konrad
 +
 
 
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:
 
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:
  
Line 7: Line 8:
 
|
 
|
 
<code>[eiffel, n]
 
<code>[eiffel, n]
class A
+
class
 +
  A
 +
 
 
feature
 
feature
   f (a: ANY) do end
+
   f (a: ANY)
 +
      do end
 +
 
 
end
 
end
 
</code>
 
</code>
 
|
 
|
 
<code>[eiffel, n]
 
<code>[eiffel, n]
class B1
+
class
inherit A redefine f end
+
  B1
 +
 
 +
inherit
 +
  A
 +
      redefine f end
 +
 
 
feature
 
feature
   f (a: STRING) do end  -- not valid
+
   f (a: STRING)
 +
      do end  -- not valid
 +
 
 
end
 
end
 
</code>
 
</code>
 
|
 
|
 
<code>[eiffel, n]
 
<code>[eiffel, n]
class B2
+
class
inherit A redefine f end
+
  B2
 +
 
 +
inherit
 +
  A
 +
      redefine f end
 +
 
 
feature
 
feature
   f (a: ?STRING) do end  -- valid
+
   f (a: detachable STRING
 +
      do end  -- valid
 +
 
 
end
 
end
 
</code>
 
</code>
 
|}
 
|}
  
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.  
+
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''. This was probably not the intention of the programmer.
 
+
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====
+
  
 +
On the other side, ECMA 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 type ''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.
  
* as is detached.
+
ECMA says nothing about the CAT-call problematic for covariant generics. If the same approach would be taken as for covariant redeclaration, a type parameter would always be of a detachable type. This further weakens the non-void typing mechanism.
  
Will a be attached to void or will it be attached to the INTEGER_REF
+
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.
This wiki discusses some of concerns related to this solution.
+
  
==Detachable type==
+
===Conclusion===
According to the new approach a detachable type can be attached to an object of "any" type.
+
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.

Latest revision as of 09:49, 7 May 2013

Author: Matthias Konrad

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: detachable 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. This was probably not the intention of the programmer.

On the other side, ECMA 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 type 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 says nothing about the CAT-call problematic for covariant generics. If the same approach would be taken as for covariant redeclaration, a type parameter would always be of a detachable type. This further weakens the non-void typing mechanism.

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.

Conclusion

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.