Detachable types - Revision history

Conaclos: remove redundant informations for object test

2013-05-07T21:37:29Z

remove redundant informations for object test

Conaclos: readability 2

2013-03-25T16:07:24Z

readability 2

Conaclos: readability

2013-03-25T16:06:48Z

readability

Conaclos: syntax update

2013-03-25T15:56:54Z

syntax update

Peter gummer: /* Expanded types */

2007-06-24T21:21:59Z

‎Expanded types

Juliant at 18:42, 24 June 2007

2007-06-24T18:42:07Z

Juliant at 17:49, 23 June 2007

2007-06-23T17:49:24Z

Juliant: /* Examples */

2007-06-23T17:45:53Z

‎Examples

Seilerm: copy from internal wiki

2007-06-23T01:54:00Z

copy from internal wiki

New page

[[Category:ECMA]]
[[Category:Catcall]]
== Introduction ==

This solution allows covariantly redefined features only to use detachable types. Through this mechanism, an object test is necessary before an argument can be used. This forces the programmer to test arguments for validity.

This is specified in the [http://www.ecma-international.org/publications/standards/Ecma-367.htm ECMA Eiffel standard 2nd edition of June 2006].

== Syntax ==

No new syntax is necessary.

== Semantics ==

In this solution, it is only allowed to covariantly redefine arguments to detachable types. This ensures that an object test is done before the use of an argument. If now a catcall happens, the object test will fail. Since the argument is of detachable type, the programmer has to handle the case where Void is passed anyway and this also handles the catcall.

== Examples ==

=== Cats and dogs ===

The definition of the CAT class changes as follows:
<e>
class CAT
inherit ANIMAL redefine eat end
feature
eat (food: ? CAT_FOOD)
do
if {cat_food: CAT_FOOD} food then
-- Use `cat_food'
else
-- either Void or an argument of type FOOD passed
end
end
end
</e>

== Issues ==

=== Weak covariance support ===

See [http://dev.eiffel.com/New_CAT_call article on dev.eiffel.com].

=== Generics ===

With the current conformance of generics, different generic derivations can be seen as if they covariantly redefined the features with formal generic parameters. For example feature <e>put</e> from the class <e>LIST</e> if you look at the signature of <e>LIST [ANY]</e> compared to <e>LIST [STRING]</e>. As with anchored types as parameters, you would also have to specify that all formal generic parameters need to be detached. This would mean that all classes which use generic parameters always have to use object tests to use the generic parameters, and Void-safety cannot be expressed on the type system level which would remove the main benefit of attached types in the context of generics.

=== Expanded types ===

The type rule specified by ECMA (VTCT, 8.11.8) defines that an expaned type cannot have an attachment mark since Void is not a valid value for it. Given that covariant feature redeclaration, especially anchored types for arguments, can only occur with detached types, this means that arguments cannot be covariantly redefined into expaned types.

The base classes like <e>INTEGER</e> which currently inherit from <e>NUMERIC</e> which only defines it's arguments as <e>like Current</e> would be invalid in their current form. Also if formal generic parameters need to be detached as explained above, generic derivations would not be allowed for expaned types if the formal generic occurs as a parameter of a feature. Especially <e>LIST [INTEGER]</e> would not be possible.

== Conclusion ==

The problems arise partially due to the fact that two concepts are mixed:
* Attachable/detachable types: A type <e>? T</e> can be attached to an object of type T or not attached at all (i.e. Void)
* Catcall arguments: In a catcall, the type of the argument can either be the expected type or the type of an ancestor version of the feature.

By using detachable types to solve catcalls, the notion of a detachable type is expaned to be able to hold types of all ancestors as well.

In addition to this, the problems with generics and expanded types show that this solution does severly limit the usefulness of covariance.

@@ Line 35: / Line 35: @@
    eat (food: detachable CAT_FOOD)
      do
-       if attached {CAT_FOOD} food as cat_food then
+       if attached food as cat_food then
          -- Use `cat_food'
        else

@@ Line 52: / Line 52: @@
 The type rule specified by ECMA (VTCT, 8.11.8) defines that an expanded type cannot have an attachment mark since Void is not a valid value for it. Given that covariant feature redeclaration, especially anchored types for arguments, can only occur with detached types, this means that arguments cannot be covariantly redefined into expanded types.
-The base classes like <e>INTEGER</e> which currently inherit from <e>NUMERIC</e> which only defines it's arguments as <e>like Current</e> would be invalid in their current form. Also if formal generic parameters need to be detached as explained above, generic derivations would not be allowed for expanded types if the formal generic occurs as a parameter of a feature. Especially <e>LIST [INTEGER]</e> would not be possible.
+The base classes like <e>INTEGER</e> which currently inherit from <e>NUMERIC</e> which only defines its arguments as <e>like Current</e> would be invalid in their current form. Also if formal generic parameters need to be detached as explained above, generic derivations would not be allowed for expanded types if the formal generic occurs as a parameter of a feature. Especially <e>LIST [INTEGER]</e> would not be possible.
 == Conclusion ==

← Older revision		Revision as of 17:45, 23 June 2007
Line 16:		Line 16:

	== Examples ==		== Examples ==
		+
		+	See the [[introduction to examples]] for information about the classes used.

	=== Cats and dogs ===		=== Cats and dogs ===

@@ Line 24: / Line 24: @@
 The definition of the CAT class changes as follows:
 <e>
-class CAT
+class
-   inherit
+   CAT
-    ANIMAL
-      redefine eat end
+inherit
 feature

@@ Line 25: / Line 25: @@
 <e>
 class CAT
-inherit ANIMAL redefine eat end
+  inherit
 feature
    eat (food: detachable CAT_FOOD)
      do
@@ Line 35: / Line 39: @@
        end
      end
 end
 </e>

@@ Line 1: / Line 1: @@
 [[Category:ECMA]]
 [[Category:Catcall]]
 == Introduction ==

@@ Line 49: / Line 49: @@
 === Expanded types ===
-The type rule specified by ECMA (VTCT, 8.11.8) defines that an expaned type cannot have an attachment mark since Void is not a valid value for it. Given that covariant feature redeclaration, especially anchored types for arguments, can only occur with detached types, this means that arguments cannot be covariantly redefined into expaned types.
+The type rule specified by ECMA (VTCT, 8.11.8) defines that an expanded type cannot have an attachment mark since Void is not a valid value for it. Given that covariant feature redeclaration, especially anchored types for arguments, can only occur with detached types, this means that arguments cannot be covariantly redefined into expanded types.
-The base classes like <e>INTEGER</e> which currently inherit from <e>NUMERIC</e> which only defines it's arguments as <e>like Current</e> would be invalid in their current form. Also if formal generic parameters need to be detached as explained above, generic derivations would not be allowed for expaned types if the formal generic occurs as a parameter of a feature. Especially <e>LIST [INTEGER]</e> would not be possible.
+The base classes like <e>INTEGER</e> which currently inherit from <e>NUMERIC</e> which only defines it's arguments as <e>like Current</e> would be invalid in their current form. Also if formal generic parameters need to be detached as explained above, generic derivations would not be allowed for expanded types if the formal generic occurs as a parameter of a feature. Especially <e>LIST [INTEGER]</e> would not be possible.
 == Conclusion ==
@@ Line 59: / Line 59: @@
 * Catcall arguments: In a catcall, the type of the argument can either be the expected type or the type of an ancestor version of the feature.
-By using detachable types to solve catcalls, the notion of a detachable type is expaned to be able to hold types of all ancestors as well.
+By using detachable types to solve catcalls, the notion of a detachable type is expanded to be able to hold types of all ancestors as well.
-In addition to this, the problems with generics and expanded types show that this solution does severly limit the usefulness of covariance.
+In addition to this, the problems with generics and expanded types show that this solution does severely limit the usefulness of covariance.